Terminology of error-oloy

[Kent M Pitman <KMP @ MIT-MC>]

    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
    operands.

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.
-kmp