Newsgroups: comp.lang.scheme
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: mkatz@garlic.stanford.EDU (Morris Katz)
Subject: open-input-file [topics from hell, part 2]
Message-ID: <9104291603.AA12211@garlic.Stanford.EDU>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
References: <9104270655.aa29839@mc.lcs.mit.edu>
Date: 29 Apr 91 16:03:42 GMT
Lines: 23

If we ever get serious about adding a condition(error) system to scheme, I
would suggest that we go back and take another look at the one in CLU.  (I
believe that this system shares a lot of commonality with CL, but I am not a CL
hacker and so have relatively little knowledge of the CL condition system.)  I
can honestly say that the CLU condition system is the only one with which I
have a fair degree of familiarity that is not IMHO completely broken.  Some of
the features it includes which I consider important are
1)  Dynamically scoped error handlers
2)  The ability to specify handlers for any set of errors and allow others to
    propogate out to dynamically enclosing scopes.
3)  A choice of how to resume computation following the handling of an error.
4)  The ability to define new error types.

The one feature which it lacks and I would like to see is a concept os a
hierarchy of errors.  By this I mean that several errors should all be
definable as a subtype of another error.  A handler for the supertype could
then handle errors for all the subtypes.  The default handler which most
systems currently support that just prints an error message on the screen would
be the handler for the error type of which all other error types are a subtype.
--------------------
Morry Katz
katz@cs.stanford.edu
--------------------