[R6RS] How SRFI 35 enables communication protocols via conditions
Anton van Straaten
Thu Jun 9 04:03:23 EDT 2005
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.
>> 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.
More information about the R6RS