References: CATCH, THROW, UNWIND-PROTECT,
Related issues: EXIT-EXTENT
Edit history: v1, 22 Feb 1991, Sandra Loosemore
v2, 11 Mar 1991, Sandra Loosemore
The EXIT-EXTENT issue doesn't specify how exit points interact with
the dynamic bindings of condition handlers and restarts. At what
point in the execution of non-local transfers of control do the
extents of handlers and restarts established by HANDLER-BIND and
Clarify that undoing of handler and restart bindings during an exit
happens in parallel with the undoing of the bindings of special variables
and CATCH tags, in the reverse order in which they were established.
The effect of this is that the cleanup clauses of an UNWIND-PROTECT
will see the same handler and restart bindings, as well as dynamic bindings
and CATCH tags, as were visible with the UNWIND-PROTECT was entered.
Presumably many implementations use dynamic bindings and CATCH to
implement handler and restart bindings.
The sample condition system implementation uses dynamic bindings and
CATCH to implement handler and restart bindings.
Cost to Implementors:
Cost to Users:
Cost of non-adoption:
Continuing vagueness in the language specification.
The cost of non-adoption is avoided.
Being consistent with issue EXIT-EXTENT is a good thing. Whether
issue EXIT-EXTENT was resolved in an esthetic manner is another
This issue was raised by Barry Margolin on the X3J13 mailing list.
Kim Barrett notes:
A consequence of this proposal is that
(throw 'foo nil)
(error () (print 'foo))))
has undefined consequences. This is why I voted against EXIT-EXTENT. Of
course, few people listened then so why should they listen now.
....[this] is a consequence of EXIT-EXTENT and has
nothing to do with EXIT-EXTENT-AND-CONDITION-SYSTEM, which speaks
only of when bindings are disestablished, not when using those
bindings becomes undefined, which is the subject of EXIT-EXTENT.
EXIT-EXTENT-AND-CONDITION-SYSTEM tells us that the handler binding
extablished by the HANDLER-CASE becomes disestablished when control
passes outside the HANDLER-CASE and not before. In particular this
binding is still established while the UNWIND-PROTECT cleanup form
is executing. It is difficult to imagine what other semantics
for this part could be defensible.
EXIT-EXTENT tells us that the exit point used by the handler established
by the HANDLER-CASE cannot be used after the THROW commences. Note that
this is not the same binding as the one discussed by
EXIT-EXTENT-AND-CONDITION-SYSTEM. It is certainly possible to imagine
other defensible semantics for this part, we spent years discussing it.
I can think of few things more horrible than re-opening the issue