[R6RS] How SRFI 35 enables communication protocols via conditions
Thu Jun 9 01:39:42 EDT 2005
> >> - 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
> 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
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.
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.
More information about the R6RS