When a problem situation, or exception, is detected either by the implementation or by a user program, a representation of that situation called a condition (which can be any Scheme object) is constructed, and the exception is announced by an action called signaling the condition. This action allows a dynamically established handler an opportunity to resolve the problem; the current handler is the value of the SRFI 39 parameter condition-handler. At any given time, only one handler is active.
When a condition is signaled, the active handler is called with one argument, a condition which represents the situation. The handler function will execute in the dynamic environment of the call to signal, except that the value of condition-handler is rebound to match the enclosing handler, which is the handler that was current at the point that the current handler function was established as the active handler. This means that handlers are not expected to handle exceptions within themselves, and may re-raise an exception by simply calling raise with the same condition. (In order to allow a handler to handle its own exceptions, the handler may re-establish itself as a handler within its own body by rebinding condition-handler to itself; this may create infinite loops if carelessly used.)
If a handler returns normally, its values are discarded, and the condition is passed to its enclosing handler until there are no more handlers. Escaping from handler control is performed by invoking a captured continuation. For example, a handler may return to the point where it was signaled by invoking a continuation stored inside the condition. Alternatively, it may return to the point where it was bound by invoking a continuation in a variable that is lexically visible to the handler. In any case, the appropriate current handler will be restored as part of the dynamic environment.
The initial condition handler is implementation-defined. It generally invokes a top-level exit continuation for the whole program, or the current thread (if some concept of threading exists), possibly displaying useful debugging information to some interested parties in some implementation-specific way. Implementations may provide an interactive debugger that lets the programmer perform actions other than invoking the top-level exit continuation, perhaps invoking retries or other arbitrary continuations.
This is a SRFI 39 parameter representing the current condition handler. Invoking it with no arguments returns the current handler; invoking it with one argument sets the current handler. Passing it to the parameterize syntax form causes it to be dynamically rebound to a new handler.
This signals the condition object. It never returns normally.
This constructs a condition using string and the optional objects and signals it. It is compatible with SRFI 23.
Thanks to Taylor Campbell, Alaric Snell-Pym as the author of ErrorsSnellPym, and Kent Pitman as the author of the ISLisp specification, from all of whom I have derived inspiration. They bear no responsibility for infelicities in this proposal.