CL condition system

["Mark A. Tapia" <markt@dgp.toronto.edu>]

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))
nil
nil

    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
 
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
  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 ().

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?