[R6RS] How SRFI 35 enables communication protocols via conditions

[Manuel Serrano]

> >> - File I/O errors that are also networking errors.
> >> - Errors that are also or may be bugs.
> > I have never faced situations where I had to compose exceptions (I don't
> > pretend that these do not exist) so I'm not absolutely convinced that this
> > is mandatory. 
> 
> What would it take to convince you?  How would you express the
> exceptional situation described above?
> 
> Some further evidence:
> 
> - SRFI 12, authored by four of the current editors (none of them me)
>   has this capability.
> 
> - The Common Lisp people and the Dylan people have come to the same
>   conclusion:
> 
> http:/ to be /www-2.cs.cmu.edu/Groups/AI/html/cltl/clm/node329.html#SECTION0033314000000000000000
> 
>   I'm sure Kent Pitman or Guy Steele could provide more background if
>   necessary.
As you suggest, if I'm not convinced it's probably because I'm too stubborn.

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. 

Anyhow, if everyone here thinks that we should adopt compound
condition types, let's do so.

-- 
Manuel