16.4.2 Invoking Standard Restart Code

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.

procedure: abort [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.

procedure: continue [restarts]

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.

procedure: muffle-warning [restarts]

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.

procedure: retry [restarts]

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.

procedure: store-value new-value [restarts]

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.

procedure: use-value new-value [restarts]

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.