[R6RS] Ticket #221 (Recursive exception handling considered harmful)

[William D Clinger]

Mike wrote:
> I'd greatly appreciate if at least one editor other than me could have
> a close look at [formal comment 221] before Wednesday.

The formal comment notes that the current draft's
exception system requires exception handlers to
decline to handle an exception by re-raising it
via a call to raise (or to raise-continuably).
Since raise itself then calls the next handler via
a non-tail call, the usual exceptional case (which
is to pass the exception to the outermost default
handler) requires time and continuation space
proportional to O(n), where n is the number of
active handlers.

The formal comment proposes to change this by
having handlers decline to handle an exception
by returning instead of re-raising.  To get around
the fact that, in the current draft semantics,
returning from a handler resumes following the
call to raise, the formal comment proposes to
eliminate raise-continuably.  Presumably the only
portable way to resume following a raised exception
would be for the program to capture a continuation
prior to raising the exception and to pass that
continuation as part of a condition or via side
effect.

The problem addressed by the formal comment doesn't
seem so dire to me, because the time required to get
to the outermost handler would remain O(n) even with
the proposed change; furthermore the current R6RS
exception system is (IMO) insufficiently useful for
n to grow very large, so O(n) space doesn't seem
like a big deal either.  Even if n were large, the
space required to represent the sequence of handlers
would already be O(n), so the O(n) non-tail calls
wouldn't change the asympotic space requirements of
the program [1].

Removing raise-continuably would make the exception
system even less useful, and would require us to
reconsider the semantics of &no-infinities, &no-nans,
&i/o-decoding, and &i/o-encoding exceptions (since
the specifications of those exceptions/conditions
rely upon continuable exceptions).

I think it would be better to rid ourselves of the
R6RS exception system altogether, or to stick with
its current semantics, than to make the changes
requested by formal comment 221.

Will

[1] You might be able to construct pathological
examples in which a program with O(n) handlers
manages to raise O(n) exceptions in such a way
as to increase the space required to O(n^2), but
I think you'd have to work at it.