Re: contracted exceptions

[Ray Blaak <rAYblaaK@STRIPCAPStelus.net>]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 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 the problem is that one cannot reliably predict in advance which
exceptions can propagate. Furthermore this set can change over time as a
system is maintained.

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

My point is that in general it doesn't matter. What happens when something
unexpected is raised anyway? You still have to have a strategy for that.

> 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.

The heavy use of 3rd party libraries in Java programs at least dictates it to
the programmer. Sure, the programmer can define better behaviours in their own
software.

Also, declaring exceptions to be propagated cause internal design artifacts to
be propagated to the public specification of the design.

A compromise approach I have seen and used myself is to let all possible
exceptions propagate freely in the internals of a subsystem, and then at the
public edges handle and wrap into the official publically allowable exceptions.

Some more modern Java libraries make use of unchecked exceptions. E.g. the
org.w3c.dom API has its root DOMException type derived from the unchecked
RuntimeException.

> > 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.

So what do embedded systems tend to do? They cannot simply halt after all.

My guess is that they handle known (i.e. expected) errors has best they can,
possibly with recovery, but unknown errors simply cause some sort of reset to
a known state. This is still a central strategy, no?

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.