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