Exception handling in R5RS

[Pavel Curtis <Pavel@parc.xerox.com>]

David Carlton's proposed exception-handling facility is more complex than it
needs to be; the mechanism provided in SchemeXerox provides more functionality
with less complexity.

The following excerpt from the SchemeXerox reference manual explains how our
system works.  I would propose just the addition of the two fundamental
constructs (RAISE and WITH-HANDLER) to R5RS, possibly along with the convenient
syntax HANDLER-CASE.  I would not propose including ERROR since it depends on
FORMAT, which is not in the language.

	Pavel


6.15. Signalling and handling errors

An exceptional condition is a situation that technicaly falls within the
contract of a system, but is not considered part of the system's normal
functioning.  For example, the procedure READ normally returns a datum parsed
from a port, but also has defined behavior when the input is not syntactically
correct (according to the Revised^4 Report, it ``signals an error'').  This
section presents a means for systems to report the occurrence of such
exceptional conditions and to notice and recover from such reports.

A signal is a Scheme value representing a particular exceptional condition; its
precise semantics is a part of the contract of the signaller, the system
reporting the condition.  For modularity reasons, we expect that most signals
will be instances of distinct, application-specific, opaque types; this allows
handlers to recognize unambiguously the meaning of a particular signal, and
signallers to control the capability to raise that signal.

A handler is a procedure of one argument, a signal currently being raised.  In
broad terms, a handler has only two choices in dealing with each signal raised:

1.	The handler may accept the signal, taking full responsibility for
	recovering from the exceptional condition.  This is usually
	accomplished by invoking a continuation captured before the handler was
	enabled.

2.	The handler may decline the signal, refusing to take final
	responsibility for recovering from the exceptional condition.  This is
	accomplished simply by returning from the handler.

Every SchemeXerox thread maintains a list of currently-active handlers.  When a
signal is raised, each handler on the list is applied to it in turn,
most-recently-activated first, in the dynamic environment of the signaller.  If
all of the handlers decline the signal, then some unspecified action takes
place; the debugger might be entered (if one is available), the thread might be
frozen (awaiting a remote debugger), etc.  We expect this to be well-defined
for any particular set of circumstances, but unspecified in general.


6.15.1. Raising and handling signals

The procedure WITH-HANDLER is the fundamental means for making a handler active
over some dynamic extent.  The new syntax HANDLER-CASE captures a particularly
common idiom.  The procedure RAISE is the fundamental means for raising
signals.  The procedure ERROR captures another common idiom.

WITH-HANDLER handler thunk	 [Procedure]

The given handler is made active during the application of thunk to zero
arguments.  Whenever control leaves the thunk, either normally or via explicit
invocation of a continuation, the handler is deactivated.  Whenever control
subsequently returns to the thunk, via invocation of a continuation created
there, the handler is reactivated.

HANDLER-CASE expression (predicate (var) body) ...	 [Syntax]

The given expression is evaluated and its results returned.  If a signal is
raised during the evaluation, each predicate in turn is evaluated (in the
dynamic environment of the signaller) and applied to the signal.  If the
application returns true, then the corresponding body is evaluated in the
dynamic environment of the HANDLER-CASE form, with the corresponding var bound
to the signal; in this case, the body's results are returned from the
HANDLER-CASE form.

RAISE signal	 [Procedure]

The given signal is raised as described above.  This procedure does not return.

ERROR format-string arg1 arg2 ...	 [Procedure]

A convenience for signalling conditions that are not expected to be handled.
Equivalent to

	(raise (format #f format-string arg1 arg2 ...))


6.15.2. Predefined signals

Several types of conditions arise frequently in practice, so it is useful to
standardize their corresponding signals.  The following sections specify the
procedures available for manipulating these predefined signals.

... several sections follow ...