[R6RS] How SRFI 35 enables communication protocols via conditions

[Anton van Straaten]

Michael Sperber wrote:
> "Manuel Serrano" <Manuel.Serrano at sophia.inria.fr> writes:
> 
> 
>>In Bigloo, I'm not using SRFI 35 nor 35. First, since the system
>>supports classes, exceptions are represented by classes. Second,
>>Bigloo exceptions are more or less a subset of Java exceptions. For
>>the sake of the example, here is, the Java exception used to denote
>>files not found.
>>
>>java.lang.Object
>>  extended by java.lang.Throwable
>>      extended by java.lang.Exception
>>          extended by java.io.IOException
>>              extended by java.io.FileNotFoundException
>>
>>As far as I can tell, I see no interface here. How is it that Java guys 
>>just happen to use classes when, if I understand you correctly, they should
>>use interfaces instead. I'm missing something. 
> 
> 
> Yes, they should.
> 
> There's a lot of things you can do with single inheritance and no
> compound conditions.  Also, there's a lot of things you can do without
> any standard condition infrastructure.  But, in my experience, you
> eventually get to a point where you the hierarchy no longer fits your
> needs.  That's when you either fiddle around with the hierarchy itself
> to unify branches you want to combine (and change all of your code),
> or you provide only partial information.  The problem with Java is
> that there's all this typing overhead associated with providing
> additional information, so these people just punt on the issue.  (I
> suspect that basic Java exception hierarchy was fixed early on, and
> couldn't be changed later because of the use in communication
> protocols.)  We shouldn't.

One change that Java made between 1.3 and 1.4 is to make the Throwable 
class (referenced in the inheritance chain above) nestable, by 
containing a "cause" field which is itself a Throwable[*].  This allows 
arbitrary-length chains of exception objects to be constructed, 
representing a chain of causes usually from highest level (outermost 
exception object) to lowest level (innermost object).

This feature is something that many people "invented" for themselves 
before Java 1.4 was released.  I did so myself.  I'm in favor of having 
some such functionality be supported in R6RS - it's often important to 
be able to represent both high-level and low-level causes of an exception.

For example, the above FileNotFoundException is a low-level exception 
which could be the cause of some higher-level, application-specific 
exception.  Single inheritance isn't good enough to model this because 
the same high-level exception may have multiple possible low-level causes.

Anton

[*] http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Throwable.html