SCL condition system

[KMP@STONY-BROOK.SCRC.Symbolics.COM (Kent M Pitman)]

    Date: Thu, 28 Jun 90 15:31 EDT
    From: barmar@Think.COM (Barry Margolin)

	Date: Wed, 27 Jun 90 19:05 PDT
	From: Charest@AI-SUN.jpl.nasa.gov (Len Charest)

	I have just started playing with the condition system in release 7.2 Genera.
	How are handlers established for the following call to ERROR?
	
		(error 'ferror :format-string "moo cow")

    When you write "how are handlers established", are you asking how the
    built-in handling of this is implemented or how you would establish a
    handler?  The latter is done using CONDITION-CASE or CONDITION-BIND to
    specify a handler forn the FERROR condition flavor (or one of its
    component flavors: ERROR, DBG:DEBUGGER-CONDITION, or CONDITION); this is
    explained in detail in book 2A of the 7.2 manual set (book 8 of the 8.0
    manuals).

Right.

	I understand that a condition object of flavor FERROR is instantiated and then
	the SIGNAL-CONDITION method is run, and ultimately the debugger is entered.
	Furhtermore, by tracing the inner workings of signal-condition I discovered that a
	handler named DEBUGGER-HANDLER is somehow established on the list of *bound-handlers*.
	So who set-up this handler? And who sets up any handlers for any call to error that
	is not lexically surrounded by forms such as condition-case, etc.???
	       ^^^^^^^^^
	       You mean "dynamically".

I suspect he doesn't.  I suspect he thinks it works lexically and is therefore
asking what happens in the dynamic case.  The answer is not that he meant
"dynamically" in his question, but rather that the whole condition system works
dynamically, not lexically, so this question is moot.

To expand just slightly--a condition system which is purely lexical is fairly
uninteresting since it only addresses the issue of cooperation between an erring
function and a piece of code which is lexically visible--i.e., it only addresses
the set of things the compiler can detect at compile time.  The problem is that
the place that `real' errors come up is in modularity boundaries between programs
that were not compiled together and for which any errors couldn't be anticipated
statically.  Such problems are much harder than those addressed by the lexical error
systems available in some other languages.  The lisp machine's approach to the
harder problem of runtime errors has been to create an object oriented protocol
for negotiating on which errors are to be handled and how, so that when an error
occurs at runtime which could not be statically detected at compile time, it can
still be dealt with reasonably.  This object-oriented approach is necessarily 
dynamic in nature, not lexical.

I hope this is enough to at least get you started.
Good luck.

    DEBUGGER-HANDLER isn't on *BOUND-HANDLERS*, it's on
    *INTERACTIVE-HANDLERS*, which is searched if no handler is found on
    *BOUND-HANDLERS*, *GLOBAL-HANDLERS*, or *DEFAULT-HANDLERS*.  It's
    initialized at boot time because it's defined with DEFVAR-RESETTABLE.

Boy, I can't believe Barry alluded to all this low-level undocumented
junk without adding a disclaimer against actually programming
directly using those things. Just to clarify: *BOUND-HANDLERS*,
*GLOBAL-HANDLERS*, and *DEFAULT-HANDLERS* are internal variables
that no user code should ever try bind directly.  I think that
*INTERACTIVE-HANDLERS* might be documented and might be appropriate
to use in a few rare cases, but you should prefer *DEBUGGER-HOOK*
in the CL Condition system when it becomes available (see below) if 
only because it will be more portably available.

Macros like CONDITION-BIND and CONDITION-BIND-DEFAULT in Zetalisp are
the right way to manipulate these internal variables because they
work at the right level of abstraction to shield you from possible
changes to the low-level implementation.  See the documentation on
conditions (cited by Barry above) for the full story.  It's much
too detailed to go into here.

	Maybe this is moot in light of the new Common Lisp Condition System...

    Well, since Genera doesn't implement the Common Lisp Condition System
    yet (it's not in 8.0, and I haven't heard whether it will be in 8.1),
    it's not yet moot.

It will be in 8.1, but in fact it will also be in 8.0.1.  It may or may
not be documented, but it will definitely be there--I patched it in myself.
In any case, it's probably close enough to the way it's documented in `my'
chapter of CLtL-2 that you can use that for interim documentation if you're
willing to tolerate a few rough edges.