Next: Finding and Invoking General Restart Code, Previous: Establishing Restart Code, Up: Restarts
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 typecondition-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 procedurewarn
establishes amuffle-warning
restart for this purpose.If there is no restart named
muffle-warning
, this procedure signals an error of typecondition-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 aretry
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 astore-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 theretry
andstore-value
restarts. If theretry
restart is used it will fail because the variable still has no value. Thestore-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.