UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT

["Scott E. Fahlman" <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
    Common Lisp:

      (loop
        (ignore-errors
          (unwind-protect (loop)
            (error))))

    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.

-- Scott