From: KMP@stony-brook.scrc.symbolics.com (Kent M Pitman)
Newsgroups: comp.lang.lisp
Subject: Re: CL condition system
Date: 14 Oct 92 22:20:22 GMT
Article-I.D.: PLANTAIN.19921014222158.1.KMP
Organization: LCS news/mail gateway
X-Unparseable-Date: Wed


    Date: Tue, 13 Oct 1992 14:10 EDT
    From: "Mark A. Tapia" <markt@dgp.toronto.edu>

    For a division by zero condition, the erroneous operand is always 0.
    There are no arithmetic-error-operands for this condition.

    You cannot access the actual arithmetic operands for the following
    conditions:
       division-by-zero
       floating-point-overflow
       floating-point-underflow

Not so.  dpANS CL says plainly the class precedence list of all three contains 
ARITHMETIC-ERROR, and every ARITHMETIC-ERROR is expected to have 
ARITHMETIC-ERROR-OPERATION and ARITHMETIC-ERROR-OPERANDS.

It is slightly more vague on what should fill this, but I can tell you that
the intent was that the implementor would not omit information just because they
thought it was not useful.  I would regard the MCL behavior as a bug.  If I did
(/ 3 0), I would expect that if a DIVISION-BY-ZERO error is signaled, then
the object would have an operator of / (or perhaps of #<Function / ...> or some
internal subroutine thereof) and operands of (3 0) or perhaps (3), but not ().

I think it's highly unlikely that your suggestion of doing
 (if (arithmetic-error-operands condition) ...)
is very useful, except insofar as that it protects you against the possibility
of systems that might (without any motivation that is obvious to me) just omit
arguments at random.

I also think it's a bad idea in your other examples for you to be calling 
SIMPLE-CONDITION-FORMAT-ARGUMENTS on a condition of type ARITHMETIC-ERROR without
explicitly verifying that the object is of type SIMPLE-CONDITION.  Functions like
SIMPLE-CONDITION-FORMAT-ARGUMENTS are not defined to merely return NIL if they get
an argument condition of the wrong type; they are permitted to go into the debugger.
And no subtype of ARITHMETIC-ERROR is defined by CL to include SIMPLE-CONDITION,
although I suppose you could create one.

In general, all errors should just be reported by doing: (princ condition stream)
or (format stream "~A" condition).  This business of trying to do case-dispatch
on the type in order to guess an error message only heads off the condition's 
ability to describe itself.

    Date: Sun, 11 Oct 1992 18:57:18 GMT
    From: "Douglas C. Merrill" <dmerrill@ils.nwu.edu>

    ... I also am confused about why sometimes the operand is part of the
    condition message, and other times is not.  For example, ... unbound-variable ...
    Can anyone explain why the argument is sometimes present by default and
    sometimes not and how to access the arg if it is not put in the message
    automatically? ...

If (TYPEP CONDITION 'SIMPLE-CONDITION) is true, you can sometimes get
additional information by looking at the format args given by
SIMPLE-CONDITION-FORMAT-ARGUMENTS.  This is arguably a data abstraction
violation though, so tread lightly.  If you pick that apart, you'll find
interesting information; but then again, if it's not documented to be
there, you might find it varies from release to release--since usually
the program author only expects the format arguments to satisfy the
format control string, and not to provide a source of data access for
onlookers who aren't using FORMAT.

By the way, the offending name in an UNBOUND-VARIABLE condition is
accessible via CELL-ERROR-NAME since unbound-variable inherits from
CELL-ERROR.  So for this one, at least, you aren't at the mercy of the
error message text.  Likewise for UNDEFINED-FUNCTION.

In general, the parts of the condition which are accessible are those
parts which the creators of that particular condition protocol
considered important for the handler to have specified.  A prerequisite
to having an accessor, though, is that you have to be able to initialize
the value, or else the accessor for the value will blow out and the
problem you are trying to flag will be compounded.  So, for example,
some error types have problems that vary so much from situation to
situation that a broad-based accessor was not possible to devise.  In
this case, the reason for not providing the accessor is usually just
that implementations varied widely enough that there was no general
agreement on whether certain information would be available or whether
the error in question would occur at all or something like that.  I'm
being perhaps overly brief, but I hope this gives you a sense of how the
broader issue was resolved.
Newsgroups: comp.lang.lisp