[R6RS] How SRFI 35 enables communication protocols via conditions

[Anton van Straaten]

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
> choice.

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 
of bug.

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.

Anton