Re: F9X twister & ADA (was: n-dim'l vectors)

["James Giles" <jamesgiles@worldnet.att.net>]

Geoff Bull wrote in message <38F3D1D3.416B3493@research.canon.com.au>...
...
> Handling may be as simple as:
> when others => Put_line ("Internal error: contact vendor);
>
>which to me is a lot better than the program simply halting in the
>middle of nowhere. I can't see the advantage of halting immediately,
>if you want to halt just don't provided exception handlers.

If you can control that.  The procedures in Ada neither declare
which exceptions they might raise, nor have any other indications
that an exception might arise.  How do you *not* provide a
handler when you don't even know what it is that you're trying
not to handle?

In any case, for most of my own code I much prefer halting
immediately.  Most "graceful" termination involves doing
things that cover up evidence that might be needed to discover
the cause of the fault (closing files, deleting temporaries, leaving
the program counter and/or the registers in different states than
the context in which the error arose, etc.).  It's only for code
written for naive public consumption that "graceful" termination
is appropriate.  And yes, in this case a clear message is
important.

>>  Mystically skipping over several
>> levels of the call tree is messy.
>
>I don't understand what you mean here.

I can't see any opportunity for confusion here.  A procedure
raises an exception and some remote ancestor process catches
it.  Say, A calls B, B calls C (which is in a separately designed
library), C calls D, etc. through the whole alphabet and several
distinct, separately designed libraries.  When Z raises an
exception, A may have a handler active for it.  The programmer
who wrote A probably isn't even aware that procedure Z exists,
much less is (s)he prepared to handle an error that arose there.

Now, a signal (as distinct from an exception) might be proper
here.  But signals are generally for external things (like: your
asynch I/O is done) or for non-specific, but fatal things (like KILL).
If Z wants to send a KILL signal and procedure A has set up
a handler for that signal (to do "graceful" termination, for
example), that's fine.  You're not pretending to be able to
handle a given specific error.  And you'll respond identically
whether the signal was internally generated or sent from the
system or the program's user.

The whole idea of libraries (and most modular programming)
is for different programmers and teams *not* to have to
know the internals of the work of others.  Yet, raised exceptions
propagate across such boundaries in an undeclared and, usually
undocumented way.

At the very least, the programmer should never allow an exception
to leave the confines of the package in which it is raised (which may
consist of many levels of procedures to be sure) without explicitly
declaring to the users of the package which public procedures
may raise an exception that the package itself doesn't handle.
What exceptions each of these may raise should also be explicitly
declared.  Yes, this means that when you add code which may
raise exceptions to a procedure, you have to recompile (and maybe
even rewrite) code which uses that procedure.  This is no different
than any other case in which you changed a procedure in a way
in which its public (interface) properties have changed.  Or, are
you claiming that an exception is not a public property of the
procedure which raises it?

Ideally, the language design itself should enforce this rule.  It's
certainly the kind of thing that should be considered when designing
an exception handling mechanism for a language which doesn't yet
possess one.

One of the nice things about discussions of this type is that
it forces the re-evaluation of previous ideas in new light.  About
three years ago I posted a suggestion for Fortran exception
handling (which was criticized and/or ignored).  Already, from
this thread I see several things I'd now suggest be done
differently.  But I still wouldn't recommend Ada as an ideal
model.
--
J. Giles