[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CL condition system

In comp.lang.lisp, I responded to a question about a problem in Allegro Lisp 
in which the condition system provides for the zero-divide condition,
an empty arithmetic-error-operation and a null arithmetic-error-operands.

The same problem occurs in MCL:

(defun test-cond (expression)
  (handler-case (eval expression)
    (arithmetic-error (condition)
                      (values (arithmetic-error-operation condition)
                              (arithmetic-error-operands condition)))))

(test-cond '(/ 3 0))

    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
Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> responds:
  Not so.  dpANS CL says plainly the class precedence list of all three contains
  ARITHMETIC-ERROR, and every ARITHMETIC-ERROR is expected to have
  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 ().

Why has MCL set the operand and operator slots in all three of these specific errors
to nil?

For example
(test-cond '(log 0))
also returns null operand and operator slots.

Are there any arithmetic-error-conditions for which the operator and
operands slots are not null?