[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Terminology of error-oloy
- To: Jim.Large @ CMU-CS-SPICE
- Subject: Terminology of error-oloy
- From: Kent M Pitman <KMP @ MIT-MC>
- Date: 16 October 1984 18:49-EDT
- Cc: cl-error-handling @ SU-AI, DLW @ SCRC-STONY-BROOK
- In-reply-to: Msg of 16 Oct 1984 17:12:18 EDT from Jim.Large at cmu-cs-spice.arpa
Date: Tuesday, 16 October 1984 17:12:18 EDT
From: Jim.Large at cmu-cs-spice.arpa
It might be easier to distinguish an "error" from the broader class of
"conditions" by looking only at the point where the error is signalled.
Perhaps an "error" is a condition signalled by some routine when
that routine has been given inconsistent inputs (its contract has been
violated by its caller) and it does not know what else to do.
By this definition, division-by-zero is an error because it is the
condition raised by the divide instruction when divide is given illegal
I believe the point Dan was trying to raise was the more subtle one that
functions may signal an error when they get inconsistent inputs is fine,
but to say they must signal an error when they get inconsistent inputs is
in fact contradictory. It is the same as saying that the program is defined
to work in a certain way when it is not defined to work. It's a messy
point. My intuition is that we should avoid any definition of error which
refers to the program's contract.
I spoke with Albert Meyer about this problem and he said the theory of
computation people don't have any agreement on the issue either. His advice
was just to muddle through it as best we could.
How about if we modified the definition to simply say that if a given
lexical contour signals an "error" (as contrasted with a "condition")
then it cannot be proceeded without externally provided advice about how to
proceed (ie, handling of some sort). People will typically use such a
facility to deal in ways that relate to contract violation, but that will
just be a point of style, not a point of definition.