[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Fri, 1 May 1987 23:26 EDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of 23 Apr 1987 02:07-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
Larry's status report says that this issue has been agreed...
I never agreed to this, and I think you are overlooking something.
Well, it should have been "agreed by those present at the pre-X3J13
meeting", I guess.
Therefore I propose that case 1, transfer to a point inside the point to
which control would have transferred, not do the second throw. There
are two things we could require it to do instead (or we could just
wimping out and say it "is an error"). It could signal an error, or
it could resume the original throw, just as if the cleanup handler had
exited normally. I prefer signalling an error, because I firmly believe
that the program is ill-formed.
I think you've spotted a case that the rest of us missed. At least, it
didn't come up in earlier discussion. I'm not completely sure what is
right, but I'm inclined to agree that "signals an error" is the right
thing here, rather than just allowing the throw whose tag is outermost
to win. I've got a hunch that trying to do the latter would just
introduce another layer of subtle problems.
Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.
I guess we need a class of errors that don't get ignored, despite the
user's instructions. There are probably some other members of this
class. Some asynchronous things that have nothing to do with the code
inside the IGNORE-ERRORS form might qualify: system almost out of
memory, memory error, and stuff like that.