event-handling approach to errors

[Henry Spencer]

> >I am deeply suspicious of event-handling primitives; I don't think I
> >have ever seen a good way of doing them.  Lots of bad ways, though.
> 
> 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?  How do
you provide a correction action for something like a subscript violation?
How do you inspect enough global context to find out what's *really* wrong?
(Note that optimizing compilers complicate the beejeezus out of figuring
out precisely where something went wrong and what to do about it.)  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?

Obviously my original comment didn't sink in:  I know of no *good* way
of doing exception handling.  Everything you describe is obviously
desirable in an exception-handling mechanism, but the details tend to
be very complex and decidedly ugly.  I have seen exception-handling
mechanisms whose description was half of the total description of the
language.  I have seen a substantial Ph.D. thesis, from a major CS
department, solely devoted to the design of an exception-handling
mechanism.  There is a marked lack of simple, general, powerful ideas
in this area.  Barring very specialized applications, the cost-benefit
ratio of anything more complex than (say) Unix signals seems poor.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry