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-errors
with the signalled condition as its value. If thunk returns normally, its value is returned fromignore-errors
.Notice that
ignore-errors
does not “turn off signalling” or condition handling. Condition handling takes place in the normal manner but conditions specialized fromcondition-type:error
are 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-condition
for 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-condition
for 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-condition
to 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
error
after 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-condition
directly and then callstandard-error-handler
ifsignal-condition
returns.
This variable controls the behavior of the procedure
standard-error-handler
, and henceerror
. It is intended to be bound withfluid-let
and is normally#f
. It may be changed to a procedure of one argument and will then be invoked (withstandard-error-hook
rebound to#f
) bystandard-error-handler
just prior to starting the error repl. It is passed one argument, the condition being signalled.
This is the procedure called internally by
warn
after it callssignal-condition
. The normal behavior ofstandard-warning-handler
is 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-report
on condition and the port.In order to simulate the effect of calling
warn
, code may callsignal-condition
directly and then callstandard-warning-handler
ifsignal-condition
returns. (This is not sufficient to implement themuffle-warning
protocol, 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-let
and is normally#f
. It may be changed to a procedure of one argument and will then be invoked (withstandard-warning-hook
rebound to#f
) bystandard-warning-handler
in lieu of writing the warning message. It is passed one argument, the condition being signalled.