Next: Finding and Invoking General Restart Code, Previous: Establishing Restart Code, Up: Restarts [Contents][Index]
Scheme supports six standard protocols for restarting from a condition, each encapsulated using a named restart (for use by condition-signalling code) and a simple procedure (for use by condition-handling code). Unless otherwise specified, if one of these procedures is unable to find its corresponding restart, it returns immediately with an unspecified value.
Each of these procedures accepts an optional argument restarts, which is described above in Restarts.
Abort the computation, using the restart named abort. The
corresponding effector takes no arguments and abandons the current line
of computation. This is the restart provided by Scheme’s REPL.
If there is no restart named abort, this procedure signals an
error of type condition-type:no-such-restart.
Continue the current computation, using the restart named
continue. The corresponding effector takes no arguments and
continues the computation beyond the point at which the condition was
signalled.
Continue the current computation, using the restart named
muffle-warning. The corresponding effector takes no arguments
and continues the computation beyond the point at which any warning
message resulting from the condition would be presented to the user.
The procedure warn establishes a muffle-warning restart
for this purpose.
If there is no restart named muffle-warning, this procedure
signals an error of type condition-type:no-such-restart.
Retry the current computation, using the restart named retry.
The corresponding effector takes no arguments and simply retries the
same computation that triggered the condition. The condition may
reoccur, of course, if the root cause has not been eliminated. The code
that signals a “file does not exist” error can be expected to supply a
retry restart. The restart would be invoked after first creating
the missing file, since the computation is then likely to succeed if it
is simply retried.
Retry the current computation, using the restart named
store-value, after first storing new-value. The
corresponding effector takes one argument, new-value, and stores
it away in a restart-dependent location, then retries the same
computation that triggered the condition. The condition may reoccur, of
course, if the root cause has not been eliminated. The code that
signals an “unassigned variable” error can be expected to supply a
store-value restart; this would store the value in the variable
and continue the computation.
Retry the current computation, using the restart named use-value,
but substituting new-value for a value that previously caused a
failure. The corresponding effector takes one argument,
new-value, and retries the same computation that triggered the
condition with the new value substituted for the failing value. The
condition may reoccur, of course, if the new value also induces the
condition.
The code that signals an “unassigned variable” error can be expected
to supply a use-value restart; this would simply continue the
computation with new-value instead of the value of the variable.
Contrast this with the retry and store-value restarts. If
the retry restart is used it will fail because the variable still
has no value. The store-value restart could be used, but it
would alter the value of the variable, so that future references to the
variable would not be detected.
Next: Finding and Invoking General Restart Code, Previous: Establishing Restart Code, Up: Restarts [Contents][Index]