Re: contracted exceptions

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> I would like to see contracted exceptions...
>
> The Java experience shows that compiler checked exception
> specifications don't work.

I don't quite agree.  I'd say the Java experience shows that the exact
rules of Java don't work very well.  But that does not imply that the
whole idea can't work well.

I think Java is on the right track here, and with a few tweaks to the
rules would work quite well.

One example of a "tweak": if (in Ada) you have:

    procedure Iterate (..., Action: not null access procedure (...));

you want some way to say "Iterate can raise anything that Action can
raise".  The actual parameter passed to Action, I mean.

Also, Java has a way to suppress the rules when appropriate,
by making the exception "unchecked".  But this method is not
flexible enough, plus they chose the wrong answer for some
of the predefined exceptions.

> A typical naive programmer, forced by the compiler to handle an exception,

Well, the compiler isn't doing the forcing, the programmer who defined
the exception is.  And you're not forced to handle it; you also have
the choice of declaring it to be propagated.

> overwhelmingly seems to do:

[...lots of reasonable complaints about Java snipped]

> If one observes what actually is needed for exception processing it tends to
> be:
>
> a) abort control flow - the current op cannot proceed.
> b) report the error to the user in a central way (in a popup, via a log,
>    whatever), and either exit or wait for the next new input/action.

True of some programs.  But many embedded systems have no use for
popping up or logging.

- Bob