#### 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.