Re: exception systems

[Kent Pitman <kmp@harlequin.com>]

   Date: Thu, 18 Apr 1996 11:07:44 +0000
   From: William D Clinger <will@ccs.neu.edu>

   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
mud.

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
before.
 
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
focus discussion.

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.

PROTOCOLS

 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
    "interactive handler".

    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.)

ORTHOGONAL ISSUES

 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.