[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: exception systems
Date: Thu, 18 Apr 1996 11:07:44 +0000
From: William D Clinger <firstname.lastname@example.org>
My point is that exceptions are a ball of mud.
I think this is a fallacy. The space of things that you might use
exceptions to implement is perhaps a ball of mud, in the same sense as
the space of things that you might write programs about is a ball of
The space of things an exception system should do is a well-understood
area about which much useful work has been done, and I think there's
no excuse for propagating the myth that this is some black art. It
simply is not. There are a very finite set of very well understood
issues in this area. There are perhaps several different ways of
approaching each, but the problem is not endless.
I feel as if calling this a ball of mud is a way of saying that it's
ok to be sloppy about the outcome, or it's not necessary to do your
homework about what's been done already because probably it won't
measure up to your high standards anyway, and it's ok to just make up
ideas on the fly and assert that they're better than what's been done
I want to applaud both Richard Kelsey and Dan Friedman, both of whom
have suffered through extensive discussions with me in order to try to
wrap their respective heads around the various issues that I keep
saying are the criteria. Richard Kelsey's proposals really make an
extraordinarily good stab at addressing what I consider the
appropriate issues head-on. To the extent that his proposals have
been insufficient, I'd like to see an example of a program you want to
be able to write and why it is hard to write in his system in order to
Here is more of what I'd like to see as criteria for acceptance of an
exception system. I'm not positive this list is complete, but I see it
as a starting point...
BASIC PROGRAMMATIC FUNCTIONALITY
1. REPRESENTING SITUATIONS
Can the exception system represent a situation in an object-oriented
way so that unrelated programs with can distinguish situations about
which they have expertise from situations about which they don't?
2. IDENTIFYING RESTART POINTS ("USEFUL" CONTINUATIONS)
Does the exception system provide a way to establish certain
continuations that might be useful in continuing from subprograms
that run into difficulty and need a non-local return point short
of a global exit? (Is there a way to later introspect to find these,
or must they be passed by explicit data flow?)
3. REQUESTING ADVICE (SIGNALING)
Does the system provide a mechanism for a program to take a condition
(a representation of a situation) and ask for aid in deciding among
possible courses of action (restart points)?
4. OFFERING ADVICE (HANDLING)
Does the system provide a mechanism for a program to offer advice.
Preferrably, this should allow the advice-giver to inspect the
condition object representing the situation to be resolved before
committing to giving advice? That is, it should offer the ability
either to give advice or to DECLINE.
5. What restart protocols does the system offer in various error
situations? e.g., if there is an unbound variable error, is there
a standard way that I can count on to supply a new value so it can
continue as if no error had occurred? What about file not found
errors and supplying a new file? Another example protocol might be
the ABORT restart to return to the nearest command level (or exit
the application, if it has no command level).
BASIC INTERACTIVE FUNCTIONALITY
6. ERROR MESSAGES
Does the system provide a way to present conditions to the user
in an appropriate natural language?
7. INPUT FROM USER
Does the system provide for the user to select among restarts
interactively, in order to allow the user the option of being
a "handler". One should think of the "debugger" as simply an
Key to this are the ability to perform (6) above, and these
two additional sub-issues:
A. Does the system provide a way to present restarts
to the user in an appropriate natural language?
B. Does the system provide a way to add the ability to prompt for
arguments needed by a restart protocol which in a program would
be supplied by the program but in the interactive mode must come
from the user. (An INVOKE-RESTART-INTERACTIVELY facility.)
8. TRAP HANDLING
Does the system allow you to manipulate floating point traps.
9. INTERRUPT HANDLING
Doe the system allow you to establish mechanisms that manage interrupts.