[R6RS] How SRFI 35 enables communication protocols via conditions
Thu Jun 9 10:42:18 EDT 2005
Marc Feeley <feeley at iro.umontreal.ca> writes:
> Moreover I think that multiple inheritance is not the right approach
> for conditions.
I agree---as I said in the message at the top this thread, compound
conditions are typically created ad-hoc, which makes (static) multiple
inheritance an awkard fit.
> I prefer the nested Throwables of Java. Let me give you an example.
> Say I have a piece of code that can either raise an "file-not-found
> condition" in a call to open-input-file or a "key-not- found
> condition" in a call to a database lookup operation. In the handler
> you test for the file-not-found condition and then the key-
> not-found condition. With compound conditions there will be a
> problem if the lookup operation uses the filesystem as a database
> (i.e. it implements the lookup with open-input-file), because both
> conditions are file-not-found conditions. By nesting conditions
> this problem is avoided, yet it is still possible to know (by
> following the nesting chain) that the key-not-found condition is due
> to a file- not-found condition.
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
chain. (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.
(define-condition-type &nested &condition
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
More information about the R6RS