[R6RS] How SRFI 35 enables communication protocols via conditions

[Michael Sperber]

Marc Feeley <feeley at iro.umontreal.ca> writes:

> On 9-Jun-05, at 10:41 AM, Michael Sperber wrote:
>
>> The Java approach seems to have the disadvantage that the regular
>> condition-type discrimination mechanism (via types in the catch
>> clauses) only applies to the outermost condition object---you have to
>> apply more elaborate tests to find specific condition types along the
>> chain.
>
> You say it is a disadvantage, but I see this as an advantage (in  
> Scheme).  I don't want the implementation of the operations to be  
> directly visible to the exception catcher, for abstraction reasons.   
> The low-level (implementation) details [...]

In the message you quote, there's the following sentence further down:

>> There certainly isn't always a natural order to the component
>> conditions.

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.

For example, in the bug vs. error scenario: it's not that one is the
*cause* of the other.  Also, in the "network vs. file-system error"
scenario, one *is* the cause for the other, but it's not clear why a
handler with a `network-error?' predicate shouldn't be able to catch
the condition.  What if, when I'm signalling the exception, I want to
talk to *either* the handler for network errors or file-system errors?
And then again, it might be that you only want to talk to the
file-system error handler---that's fine too, but the programmer ought
to have a choice.  Moreover, there's the more general question of how
you aggregate additional information to an existing condition object,
even though you have no new information about its type.

Thus, the Java approach weakens the communication protocol you can
specify with the condition mechanism, and thus makes it much less
expressive and useful than it could and should be.  I suspect it was
put into Java mainly because they couldn't change the condition-type
hierarchy for backwards-compatibility reasons.

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