Next: Restarts, Previous: Error Messages, Up: Error System
The occurrence of a condition is signalled using
signal-condition. signal-condition attempts to locate and
invoke a condition handler that is prepared to deal with the type
of condition that has occurred. A condition handler is a procedure of
one parameter, the condition that is being signalled. A procedure is
installed as a condition handler by calling
bind-condition-handler (to establish a handler that is in effect
only while a particular thunk is executing) or
bind-default-condition-handler (to establish a handler that is in
effect permanently). As implied by the name, handlers created by
bind-default-condition-handler are invoked only after all other
applicable handlers have been invoked.
A handler may process a signal in any way it deems appropriate, but the common patterns are:
signal-condition.
signal-condition with either
the same condition or a newly created one. In order to support this,
signal-condition runs handler in such a way that a
subsequent call to signal-condition sees only the handlers that
were established prior to this one.
As an aid to debugging condition handlers, Scheme maintains a set of
condition types that will cause an interactive breakpoint to occur prior
to normal condition signalling. That is, signal-condition
creates a new repl prior to its normal operation when its argument
is a condition that is a specialization of any of these types. The
procedure break-on-signals establishes this set of condition
types.
Executes thunk with a condition handler that intercepts the signalling of any specialization of
condition-type:error(including those produced by calls toerror) and immediately terminates the execution of thunk and returns from the call toignore-errorswith the signalled condition as its value. If thunk returns normally, its value is returned fromignore-errors.Notice that
ignore-errorsdoes not “turn off signalling” or condition handling. Condition handling takes place in the normal manner but conditions specialized fromcondition-type:errorare trapped rather than propogated as they would be by default.
Invokes thunk after adding handler as a condition handler for the conditions specified by condition-types. Condition-types must be a list of condition types; signalling a condition whose type is a specialization of any of these types will cause the handler to be invoked. See
signal-conditionfor a description of the mechanism used to invoke handlers.By special extension, if condition-types is the empty list then the handler is called for all conditions.
Installs handler as a (permanent) condition handler for the conditions specified by condition-types. Condition-types must be a list of condition types; signalling a condition whose type is a specialization of any of these types will cause the handler to be invoked. See
signal-conditionfor a description of the mechanism used to invoke handlers.By special extension, if condition-types is the empty list then the handler is called for all conditions.
Arranges for
signal-conditionto create an interactive repl before it signals a condition that is a specialization of any of the types in the list of condition-types. This can be extremely helpful when trying to debug code that uses custom condition handlers. In order to create a repl when any condition type is signalled it is best to actually put a breakpoint on entry tosignal-condition.
Called internally by
errorafter it callssignal-condition. Normally creates a new repl with the prompt"error>"(but seestandard-error-hook). In order to simulate the effect of callingerror, code may callsignal-conditiondirectly and then callstandard-error-handlerifsignal-conditionreturns.
This variable controls the behavior of the procedure
standard-error-handler, and henceerror. It is intended to be bound withfluid-letand is normally#f. It may be changed to a procedure of one argument and will then be invoked (withstandard-error-hookrebound to#f) bystandard-error-handlerjust prior to starting the error repl. It is passed one argument, the condition being signalled.
This is the procedure called internally by
warnafter it callssignal-condition. The normal behavior ofstandard-warning-handleris to print a message (but seestandard-warning-hook). More precisely, the message is printed to the port returned bynotification-output-port. The message is formed by first printing the string"Warning: "to this port, and then callingwrite-condition-reporton condition and the port.In order to simulate the effect of calling
warn, code may callsignal-conditiondirectly and then callstandard-warning-handlerifsignal-conditionreturns. (This is not sufficient to implement themuffle-warningprotocol, however. For that purpose an explicit restart must be provided.)
This variable controls the behavior of the procedure
standard-warning-handler, and hencewarn. It is intended to be bound withfluid-letand is normally#f. It may be changed to a procedure of one argument and will then be invoked (withstandard-warning-hookrebound to#f) bystandard-warning-handlerin lieu of writing the warning message. It is passed one argument, the condition being signalled.