Re: a safer and more efficient exception system

[William D Clinger <will@ccs.neu.edu>]

> It would be nice if we didn't have both exceptions and conditions.
> What is the advantage of not using one type of exception/condition
> object be used for both purposes?

Efficiency.  The information that is contained within an
exception object is known very early.  Most of the information
that is contained within a condition object is not known until
an exception is signalled.

With my rearrangement of Kelsey's proposal, you don't have to
allocate any storage to signal most exceptions.  A condition
is allocated only when multiple inheritance is required, or
when the handler needs to pass information to a restart.

> Some of the losses are important.  In your proposal every
> exception includes a default restart that is invoked by
> returning from a handler.  Because of this you cannot raise
> an exception and know that the raise call is not going to
> return.  I think that this is a real safety problem.

Five-minute exercise:  Write SIGNAL-AND-DONT-RETURN using only
SIGNAL and the rest of my rearrangement of Kelsey's proposal.

> Also, the value of having inheritance for exception types
> is greatly reduced.  Instead of being encapsulating in a
> data structure (what I called a condition) the information
> associated with an exception is passed as additional arguments
> to the handlers.  The arguments passed with an exception of a
> particular type have to be compatible with those of all of
> the exception type's superclasses.  If two exception types
> have incompatible argument conventions you cannot make a new
> type that is a subclass of both.  Or rather, you can make it
> but handlers for the superclasses will break when they get an
> instance of the new class.

I think this is the most serious problem with my rearrangement
of Kelsey's proposal.  I also don't think it is very serious.

You can think of my rearrangement as being optimized for single
inheritance, which suffices for most uses of an exception system.

Not all exceptions can be used as superclasses for multiple
inheritance.  The handlers for exceptions that can be so used
should take a condition (or some other data type that can
handle multiple inheritance) as their argument.  Storage
allocation will be required when signalling these exceptions,
but will not be required when signalling an exception that cannot
be used as a superclass for multiple inheritance.

> There you have me.  Out of curiosity, does that ten instructions
> include the call to the handler or just the signalling/returning
> overhead?

It includes the call to the handler.  Note, however, that this
estimate is for a tail-recursive call to SIGNAL, and that I am
assuming SIGNAL is inlined.

> I don't understand why the time to raise an exception, handle it,
> and then invoking a restart should need to be on the same order
> as the time to do a non-tail-recursive procedure call.  That is
> asking a lot.

Yes, but it is achievable and desirable for my purpose #5.
We shouldn't give up on this level of performance unless
we're getting something important in return.

One possible compromise is to layer a "condition" system similar
to Kelsey's proposal on top of a faster "exception" system that
is more similar to my rearrangement of that proposal.  This is
probably what I'll have to do anyway if something similar to the
Kelsey proposal is adopted.  This implies that the native
"exception" system will always get the first crack at handling
an exception, with the R5RS "condition" system becoming involved
only as a last resort.

To avoid confusion between these two systems, I'd like to request
that the slower systems be called "condition" or "error" systems,
since they seem to be optimized for the case in which a condition
is allocated and some kind of interactive error recovery is likely.

Will