[R6RS] How SRFI 35 enables communication protocols via conditions

[Michael Sperber]

Anton van Straaten <anton at appsolutions.com> writes:

> 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.  [...]

After thinking about it longer, I realized that I'd probably also come
to this conclusion if I'd been working in the Java mindset, which
seems focussed on providing a highly structured, exact description of
the exceptional situation.  You nail it down very clearly:

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

This means that you need and get a high level of agreement between the
thrower and the catcher.  This works within the Java mindset, but it
doesn't work well when you're trying to connect two parts of a program
that don't know about each other (or at least only one knows about the
other, but not the other way around).

SRFI 35 adheres to a completely different mindset, however, which is
that conditions are about communicating and aggregating as much
information as possible about the exceptional situation so an
exception handler (or a restart handler, which we probably don't want
to talk about in R6RS, but may want to add later) can make a highly
informed choice.  That's why condition types in SRFI 35, as often as
not, do not describe a "kind of exception" but rather a "morsel of
information" (most prominently, &message).  One could imagine
separating these two notions, but it's not clear what the benefit
would be.

If you don't provide a rich infrastructure for the exception protocol,
you're likely to slip into a different mindset and not use conditions
for many things they're potentially good for.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla