Proposed agenda

["David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>]

Here is a list I made some years ago of issues that ought to be addressed
by the Common Lisp "error-handling system".  I have updated the list
somewhat from what I wrote back then, in case anybody has seen it before.
Perhaps this will be helpful in focussing the discussion on something more
concrete than terminology.


Recognize that we want to deal in ERRORS (events that prevent the program
that detected the event from continuing to execute without intervention),
NON-ERROR CONDITIONS (events that can safely be ignored), and DEBUGGER
CONDITIONS (events that prevent the program that detected the event from
continuing to execute without intervention, but ought not to be intercepted
by "catch all errors" mechanisms).

Provide names for unusual conditions (including but not limited to errors)
and a taxonomic system for classifying those names.  A name can be defined
to include one or more other names; this inclusion relation is transitive.
For example, division-by-zero includes arithmetic-error; no-such-version
includes file-not-found, which in turn includes file-error.  All of the
above include error, a very general condition name.  If X includes Y, then
X is a more specialized version of Y.  This taxonomic system makes it
possible to handle generic classes of errors, as well as specific errors.

Add SIGNAL, which is like WARN but doesn't print anything if the condition
is not an error and not a debugger condition.

Extend ERROR, CERROR, WARN, SIGNAL, and BREAK to permit signalling conditions
by name.  (Perhaps also extend CHECK-TYPE and ASSERT the same way).  If
a symbol appears where the current syntax calls for a format-string argument,
the symbol is the name of the condition.  The interpretation of the remaining
arguments after the symbol depends on the particular condition.  A common
technique is to take the next argument after the symbol to be a format string
and the remaining arguments to be arguments to that format string.  Another
common technique is for the condition name to imply the format string and
for the remaining arguments to be &key arguments that specify various relevant
quantities.  Since any program that signals a condition must necessarily
understand the meaning of that condition, there is no need to enforce a
uniform protocol on these arguments, just as there is no need for all functions
to take exactly the same arguments.

Ways to establish condition handlers, so that programs may respond to
conditions, by throwing out, by continuing, or by correcting the reason for
the condition and retrying.  We have developed a number of special forms
that are convenient to use in this context; the most useful subset includes
CONDITION-BIND, CONDITION-CASE, IGNORE-ERRORS, and CATCH-ERROR-RESTART,
although there are several others that may or may not be worthwhile.

Ways to define the behavior and relationships of conditions.  This
presumably involves a DEFINE-CONDITION special form that defines the name
of the condition, the names of the conditions that it includes, the
arguments to be supplied when signalling the condition, documentation, and
control over how the condition prints its error message and how it can be
recovered from.

Define the protocol by which a condition handler can obtain the arguments
that were supplied when the condition was signalled, can determine what
ways of recovering from the condition are available and invoke one of them,
and can choose either to supply values needed for recovery or to let the
condition system prompt the user interactively for the values.  This
involves a three-way handshake between the program that signalled the
condition, the program that handled the condition, and the condition
definition (which acts as the interface between the other two).  We have
developed the concept of "proceeding" and "proceed types" for this purpose.

Ways to use conditions as inter-module interfaces.

Ways to use conditions to customize the behavior of the interactive
debugger.  Ways to use condition handlers to write new interactive
debuggers for specialized applications.

--- other related issues ---

Formalization of the notion of "aborting a program," and provision of
mechanisms to define where control will be thrown to when the program is
aborted, as well as a function to abort the program.  This is more
complex than it seems because of interaction with the interactive
debugger and the condition system.

Standardization of conditions signalled by the system for various "signals
an error" cases.  Standardization of conditions signalled by those
implementations that do signal errors in various "is an error" cases.
Portable floating-point exception, overflow, and rounding control, with
some provision for different levels of implementation of the standard by
different systems, depending on their hardware.

Facilities making it possible for a user to write a portable debugger.
This is a major project.

A way to define the default description string for a user-defined type,
used when CHECK-TYPE is called with only two subforms.  This can of
course be a function of the type's parameters when the type is not
simply a symbol.