[R6RS] How SRFI 35 enables communication protocols via conditions
Anton van Straaten
Fri Jun 10 13:42:04 EDT 2005
Michael Sperber wrote:
> It just isn't always about "low-level vs. high-level." (In fact, in
> my experience, it usually isn't) It's also (and, in my experience,
> mostly) about aggregating information you have and making it
> accessible in a consistent manner. With the Java approach, you always
> have to pick which one is outermost, but there isn't always a clear
In my experience, there's _usually_ a clear choice. The typical pattern
in Java programs that use nested exceptions is that an exception is
thrown and caught somewhere upstream that's expecting it. That handler
may decide to wrap it in another exception object containing info
appropriate to its context, and throw that new exception. This may be
repeated until a top-level handler is reached. This does tend to result
in the exception objects being nested from high-level at the outermost
to low-level for the innermost. At any given level in the program,
handlers catch exceptions appropriate to that level. It works out
pretty well for the most part.
When a handler wraps an exception in another exception object, then
upstream handlers have a simple choice: they either have to catch the
exact outer exception, or catch more general exceptions, and then
inspect them to figure out what to do with them. The latter may not be
ideal, but in itself this is not such a big problem in Java, because of
the static exception type checking.
In Java, the programmer always has to explicitly declare and match the
types of exceptions that are thrown and caught before a program will
compile. This forces upfront design of exception handling, and the
compile-time checking limits the ability to get this wrong or cheat.
In Scheme, without static checking, an attempt to make use of nested
exception objects has the potential for creating bugs: a piece of code
that wraps an exception risks having the invoking code fail to catch
that exception, even when an inner exception matches what the invoking
code's handler expects.
Support for SRFI-35 style compound conditions would eliminate this class
That doesn't mean I think R6RS requires compound conditions, by the
"would it be a failure without them?" criterion, but I think there's a
potentially important benefit here that ought to be considered.
More information about the R6RS