Newsgroups: comp.lang.scheme
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: pavel@parc.xerox.COM (Pavel Curtis)
Subject: Re: REPOST : Exception handling - how to define it ?
Message-ID: <91Apr8.140317pdt.40706@lambda.parc.xerox.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
References: <BEVAN.91Apr5090348@panda.cs.man.ac.uk>
Date: 8 Apr 91 21:03:08 GMT
Lines: 90

I believe that there is no standard way to define and use exceptions in
portable Scheme programs, so you may as well use any of your proposed
mechanisms.  I don't think that you'll be particularly pleased with any of
those solutions in the long run, however, on the ground of either performance,
maintainability, or flexibility.

We have a mechanism in SchemeXerox that I will (at some appropriate point)
propose for inclusion in R5RS; it works as follows (this is quoted from the
current SchemeXerox reference manual):

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
proposal 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 more sections detailing the signals raised by various standard
procedures ...

	Pavel Curtis