Common Lisp the Language, 2nd Edition
Next: Printing Conditions
Up: Survey of Concepts
Previous: Resignaling Conditions
A
handler is a function of one argument, the condition to be handled. The
handler may inspect the object
to be sure it is ``interested'' in handling the condition.
A handler is executed in the dynamic context of the signaler, except that the
set of available condition handlers will have been rebound to the value that
was active at the time the condition handler was made active. The intent of
this is to prevent infinite recursion because of errors in a condition handler.
After inspecting the condition, the handler should take one of the following
actions:
-
It might decline to handle the condition (by simply returning). When
this happens, the returned values are ignored and the effect is the same
as if the handler had been invisible to the mechanism seeking to find a
handler. The next handler in line will be tried, or if no such handler
exists, the condition will go unhandled.
-
It might handle the condition (by performing some non-local transfer
of control). This may be done either primitively using go, return, or throw,
or more abstractly using a function such as abort or invoke-restart.
-
It might signal another condition.
-
It might invoke the interactive debugger.
In fact, the latter two actions (signaling another condition or entering the
debugger) are really just ways of putting off the decision to either handle
or decline, or trying to get someone else to make such a decision. Ultimately,
all a handler can do is to handle or decline to handle.
Next: Printing Conditions
Up: Survey of Concepts
Previous: Resignaling Conditions
AI.Repository@cs.cmu.edu