Path: utzoo!mnetor!uunet!husc6!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William E. Sommerfeld)
Newsgroups: comp.lang.c
Subject: Re: Put your code... (was Re: gotos
Message-ID: <4938@bloom-beacon.MIT.EDU>
Date: 28 Apr 88 03:46:23 GMT
References: <2597@ttrdc.UUCP> <165600044@uiucdcsb> <2030@optilink.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William E. Sommerfeld)
Organization: Massachusetts Institute of Technology
Lines: 30

In article <2030@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes:
>Since the objective is do some cleanup (close the editor's files, spray
>error messages on the user's screen, post an article about the failure
>on USENET, etc.) before giving up, the correct solution is;
>
>if (failure)
>    ErrorHandler(__FILE__, __LINE__);
>
 [error handler prints a message on stdout and exits]
>
>Note that this gives the catastrophic failure cleanup the poster was saying
>was needed before killing the process, without the evil goto.  

This assumes that the only way to recover is to kill off the process
completely.  In UNIX, where each user-typed command starts a new
process, this almost makes sense, since it returns you to the shell. 

However, there are environments where killing off the process in
response to an error is not acceptable--editors, shells, or network
server processes come to mind here, as does the kernel.  You want to
be able to gracefully unwind the stack, freeing up resources and
unlocking locks as you go.  People familiar with PL/I's 'on cleanup'
and LISP's 'unwind-protect' should understand what I mean here...  At
least there are some approximations to this under UNIX... both Amdahl
and Apollo have implemented simple exception handling mechanisms on
top of setjmp/longjmp; Amdahl talked about theirs (used for exception
handling in the kernel) at the last USENIX, and Apollo uses their
implementation in NCS (their remote procedure call package). 

				- Bill