[R6RS] How SRFI 35 enables communication protocols via conditions
Thu Jun 9 11:03:22 EDT 2005
On 9-Jun-05, at 10:41 AM, Michael Sperber wrote:
> The Java approach seems to have the disadvantage that the regular
> condition-type discrimination mechanism (via types in the catch
> clauses) only applies to the outermost condition object---you have to
> apply more elaborate tests to find specific condition types along the
You say it is a disadvantage, but I see this as an advantage (in
Scheme). I don't want the implementation of the operations to be
directly visible to the exception catcher, for abstraction reasons.
The low-level (implementation) details are there if you need to get
to them but I expect most exception catchers to be interested in the
exceptions declared in the spec for the operations (as opposed to the
implementation of these operations). Of course (in Scheme) nothing
prevents someone from defining predicates that walk down the "cause"
chain to match the condition they are interested in if they wish to
break the abstraction.
> (It may be they added more magic to make this work---maybe
> Marc or Anton could help elucidate.) There certainly isn't always a
> natural order to the component conditions.
> Having an explicit nesting chain is also no problem with SRFI 35.
> Just add:
> (define-condition-type &nested &condition
> (inner nested-condition-inner))
Sure SRFI 35 is more general. That's my point. It is overkill (in
the sense that compound conditions are not necessary).
More information about the R6RS