event-handling approach to errors

[Norman Diamond]

> > There are very good systems that use a stack-discipline exception mechanism.
> > Upon an error, the most recently set error handler is given a chance to
> > interpret the error, and either provide a correction action at the point
> > of error, provide a failure alternative at a point of call (a la setjmp), or
> > pass the error (or a modified form of the error) to the next most recent
> > handler.  A system-established default handler at the bottom of the stack
> > will print a message and exit if no user-defined action is taken.

> What happens if an exception occurs within an exception handler?

Each exception handler is established at a particular level in the stack.  If
an exception handler blows up, then its level in the stack has the exception,
and earlier-level handlers may be invoked....

> How do
> you provide a correction action for something like a subscript violation?

Usually such a case is not correctable.  If the code has a bug, it doesn't
matter if good exception handlers or bad exception handlers are available;
the answer is to print a message (maybe dump, maybe ask the user if he wants
a dump), and die.

Of course, there are occasionally uses.  Someone in a numerical application
could decide that everything out of range is 0.  Someone doing quicksort could
decide that the left end always compares lower, and the right end always
compares higher -- though they'd have to return to the appropriate part of
the code.  This may improve efficiency if the hardware provides checking of
array bounds.  It is ugly of course.  (The assembly language I wrote quicksort
in is also ugly.)

> How do you inspect enough global context to find out what's *really* wrong?

Ah!  The real problem!  That, I don't know the answer to.  Maybe an AI
program can read a dump.

> Most
> particularly, how do you make it clear in the source that all this odd
> behind-the-scenes machinery may be invoked at random times?

How do you make it clear in the source code that execution time errors
might cause the program to abort?  Or that in critical applications
(including operating systems), behing-the-scenes machinery has to be
invoked to attempt a recovery, anyway?

> Obviously my original comment didn't sink in:  I know of no *good* way
> of doing exception handling.

Perfect exception handlers will be delivered with perfect programming
languages and perfect operating systems.  Meanwhile, why ignore useful tools
when they're available?  Really Henry, you usually aren't that shortsighted.

-- 

   Norman Diamond

UUCP:  {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy at waterloo.csnet
ARPA:  ndiamond%watdaisy%waterloo.csnet at csnet-relay.arpa

"Opinions are those of the keyboard, and do not reflect on me or higher-ups."