event-handling approach to errors
Henry Spencer
henry at utzoo.UUCP
Thu Mar 7 10:11:45 AEST 1985
> > 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?
I have thought for a long time that absence of most execution-time errors
is a statically-checkable property, given some cooperation from the
language and the programmer. That aside... One thing that helps is if
the association of exception handlers with code in which they handle
exceptions is static rather than dynamic. I.e., which blocks enclose
which others, rather than who gets called before who. Unfortunately,
this aggravates things like the exceptions-inside-handlers issue, and
makes them significantly less useful.
> > 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.
Note that I didn't ask for a perfect exception handler, just a good one.
I haven't seen any. Mechanisms resembling Unix signals are too simple
to do all you want. Anything fancier seems to invariably end up in
the trap of more and more features, with the result of extreme complexity
and singularly poor cost:benefit ratio. And it *still* doesn't do all
you want.
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
{allegra,ihnp4,linus,decvax}!utzoo!henry
More information about the Comp.lang.c
mailing list