Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: event-handling approach to errors
Message-ID: <5182@utzoo.UUCP>
Date: Wed, 6-Mar-85 19:11:45 EST
Article-I.D.: utzoo.5182
Posted: Wed Mar  6 19:11:45 1985
Date-Received: Wed, 6-Mar-85 19:11:45 EST
References: <149@ISM780B.UUCP> <5149@utzoo.UUCP>, <7028@watdaisy.UUCP>
Organization: U of Toronto Zoology
Lines: 39

> > 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