Re: What happens when no handler is found?

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: 6 Jan 1986 21:55-CST
    From: marick@gswd-vms.arpa

    Okay, you've convinced me that programs might very often signal
    conditions without handlers; often enough that it ought to be 
    simple to do.  Nevertheless, I still think there is a class of
    conditions (perhaps exemplified by EOF) where

    1.  It is a programmer error if there is no handler.
    2.  It's inelegant to consider the condition a subtype of ERROR.
    3.  A missing handler is better reported as MISSING-HANDLER
	than ERROR:  EOF.

    Of course, it's simple enough to make a subtype of CONDITION
    called MUST-BE-HANDLED-CONDITION and a global handler for it
    that signals the programmer error.  Should that condition and
    its handler be part of the standard?

It is a part of the standard and it is called ERROR.

My proposal allowed for a default handler for any condition type. By default, 
errors have a default handler which enters the debugger non-continuably.
In practice, this forces any condition of type ERROR to be handled, even 
when signalled with SIGNAL. However, the reason this happens is not an explicit
property of SIGNAL, it is a property of the default condition handler.

I think we're not in disagreement, so let me recap the behavior and the
rationales...

You can create types of conditions which enter the debugger non-continuably.
We'll call such conditions "error conditions". Typically, they behave this way
because they inherit from ERROR, though in fact you could create conditions 
which don't inherit from ERROR but still behave this way. Moon calls 
conditions which aren't errors "simple conditions". I'll use that terminology.

If an error condition is signalled with SIGNAL but not handled, its default 
handler will cause it to enter the debugger non-continuably. If a non-error
condition is signalled with SIGNAL but not handled, SIGNAL will return NIL
because their is no default handler.

If an error condition is signalled with ERROR but not handled, its default
handler will cause it to enter the debugger non-continuably. If a non-error
condition is signalled with ERROR but not handled, the internal call to SIGNAL
made by ERROR will return but ERROR itself will force things into the debugger
non-continuably.

Here's another way of looking at it...

				ERROR			SIGNAL
	
	Error Condition		Enter Debugger		Enter Debugger
	
	Simple Condition	Enter Debugger		Return NIL

Typically you use ERROR when you don't want to proceed and SIGNAL when you
don't mind proceeding. The ability to create conditions which cannot be 
proceeded even if the signaller didn't think it was an error is a concession
to exactly the sort of concern you seem to have, which is that there might
be no reasonable way to proceed from some kinds of conditions.

By the way, you might be interested to know that I personally disagree with
you even though my proposal does not disagree with you. I don't personally 
like the idea that it's a property of the condition and not of the signaller 
that you enter the debugger. It has always seemed to me that 
(SIGNAL 'UNBOUND-VARIABLE ...) should be treated differently than
(ERROR 'UNBOUND-VARIABLE ...). There are interesting situations where I think
this difference could be usefully and interestingly exploited. My point is
that this proposal is really not based so much on my personal feelings about
how things should be done. It is based on my experience with actually using
the Lisp Machine error system as implemented since its introduction a few
years ago. It essentially tries to lift the important features of that system 
as directly as possible while staying within the CL framework just so that 
people can have the confidence of knowing they are getting something that has
in some sense been field-tested.

-kmp