[R6RS] How SRFI 35 enables communication protocols via conditions

Michael Sperber sperber
Thu Jun 9 02:41:36 EDT 2005

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

The advantage with SRFI 35 is that you have to commit less structure
to the type hierarchy, and that allows the hierarchy to stay more

As a simple example, &message is orthogonal to the other condition
types, rather than being set in stone at the top.  Also, look at the
PLT exception type hierarchy, which has a *mandatory*
CONTINUATION-MARKS field, even though it should be a purely optional
piece of information, separated into a different condition type.

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

More information about the R6RS mailing list