event-handling approach to errors

[John Wenn]

>Personally, I think that the only realistic way to do exception handling
>is to have another process handle the exception, if only because there
>is no other way to guarantee an intact environment when an exception hits.
>But I have no idea how to arrange the details.
>				Henry Spencer @ U of Toronto Zoology

If you want to see a reasonably good and complete signal mechanism, look into
Mesa (a Xerox homegrown language, from the same company that brought you
SmallTalk).  You can do all the normal things you would expect:  normal
signals, attaching handlers to blocks or statements, passing parameters
through the signal, aborting the operation, retrying the operation from the
beginning, continuing the operation, and continuing with new parameters (e.g.
growing an array or string);  and a few things you would not think of
immediately:  deciding that you can't handle the exception after all (which
causes it to look for another exception handler up the call chain), signals
inside of exception handlers, and notification that your operation is being
aborted (which is useful to clean up data inside of monitors, for instance).

It does indeed work by calling run-time machinary that starts a new process
which looks through the call stack for possible exception handlers, and
handles any results (aborting, continuing, etc.).  If there is no handler for
the exception, the debugger is called with the complete environment of the
exception intact. Mesa is run on Xerox homegrown workstations (Dolphin,
Dandelion, Dorado, aka 1100, 1108, 1132 aka 8010) with its own operation
system.  The details of the signal mechanism is messy, but not much more than
you would expect for something this complex.

/john wenn