[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CL condition system
- To: firstname.lastname@example.org
- Subject: CL condition system
- From: "Mark A. Tapia" <email@example.com>
- Date: Thu, 15 Oct 1992 12:10:11 -0400
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)
(values (arithmetic-error-operation 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
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
(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?