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 condition handler an opportunity to resolve the problem. 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 current condition handler becomes 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 a handler is not expected to handle conditions signaled within its dynamic extent.
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 outermost 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.
See StandardConditionPredicatesCowan for standard predicates and accessors useful with implementation-defined conditions.
Returns the current condition handler.
Applies thunk within a dynamic environment in which the current condition handler is `handler.` The supplied handler is executed in the dynamic environment of the call to signal that signals the condition, except that the condition handler which was in effect when with-condition-handler was called is reinstated for the dynamic extent of the handler, so if it signals any conditions without explicitly changing to a different dynamic environment through applying continuations, they will be passed to the previous handler, not the same one.
Signals the condition object. It never returns normally.
Constructs a condition and signals it. The condition specifies a problem with an object identified by the string or symbol who that is described by string. The optional irritants are other objects relevant to the exception. The predicates who-condition, message-condition and irritants-condition return #t on this condition. This procedure is compatible with R6RS error.
Constructs a condition and signals it. The condition specifies a problem that is described by string. The optional irritants are other objects relevant to the exception. The predicates message-condition and irritants-condition return #t on this condition. This procedure is compatible with R6RS error.
Thanks to Taylor Campbell, Alaric Snell-Pym as the author of ErrorsSnellPym, Kent Pitman as the author of the ISLisp specification, and the editors of R6RS, from all of whom I have derived inspiration and stolen descriptions. They bear no responsibility for infelicities in this proposal.