Re: What happens when no handler is found?

[Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>]

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

		   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.

While everything Moon said about debugger-conditions is correct, it is
nevertheless the case in our error system that END-OF-FILE is a subtype
of ERROR.  Why is this inelegant?  Can you explain to me a relatively
formal criterion by which any given kind of event can be classified,
such that END-OF-FILE is not an error but DIVIDE-BY-ZERO is?  I don't
think there is any real difference.  Just because one is more likely to
write a program that intentionally signals END-OF-FILE than a program
that intentionally signals DIVIDE-BY-ZERO does not change the fact that
the two are essentially simiar: they are exceptional cases that the
programmer usually wants to not worry about.  That is, when you do a /,
you normally just assume that the answer is a number and keep on going,
and when you do a read, you normally just assume that the answer is a
Lisp expression and keep on going.  If you want to deal with the
possibility that the answer is not a number, or that end-of-file was
reached, you use the condition mechanism.  (In the case of READ you
can also use the extra args, but that's not relevant.)  If the exception
comes up and the programmer didn't prepare for it explicitly, in both
cases it is equally correct to enter the debugger, because the program's
assumptions have been made untrue and the program cannot proceed.