Re: What happens when no handler is found?

[marick@gswd-vms.arpa (Brian &)]

Actually, when you state my position that way, *I* disagree with me.  I do
think that what happens when there's no handler should be determined by the
signaller.  The MUST-BE-HANDLED-CONDITION was just a way to include the kind
of default semantics I want for SIGNAL into your proposal as a simple
addition of text.

Now, what I want matters not a whit, but I think others might want the same
thing.  If you look at the exception handling schemes of CLU or Ada or Mesa,
you'll find that an uncaught signal "signals an error".  (In Ada, "the task
is terminated".  In Mesa, "drastic action must be taken ... all signals will
ultimately be caught and reported by the Debugger".  In CLU, an uncaught
exception signals the special FAILURE exception -- which is pretty much what
I want.)  I don't think the experience that went into (and came out of) these
languages is irrelevant.

So I propose that ERROR be used to signal conditions the signalling code
thinks are errors.  Unhandled errors go to the debugger.  SIGNAL is used to
signal "shouts into the wilderness".  There's no expectation that anyone
will necessarily be listening, so NIL is returned if there's no handler.
ESIGNAL (named by loose analogy to ETYPECASE) is used when the signalling
code expects there to be a handler.  If there's no handler, ESIGNAL signals
an error.  Signals sent for different reasons should be sent by different 
functions.

(Actually, I'd even go so far as to propose that SIGNAL be used for
signalling-with-handler-expected, since that's the name used in other
languages for that behavior.  New names for new ideas.  Part of what
confused me initially may have been my automatic association of "signal"
with traditional exception handling, and I don't think I'm all that much
stupider than the average person.)

Brian Marick