Sam Steingold <···@goems.com> writes:
> >>>> In message <·····················@195.138.129.34>
> >>>> On the subject of "Re: upgrading errors"
> >>>> Sent on Sun, 2 May 1999 11:21:06 +0300
> >>>> Honorable Vassil Nikolov <········@poboxes.com> writes:
> >>
> >> I think that what Kent Pitman meant was that you ought to define an
> >> appropriate initarg, e.g. :PROBLEM (and provide the necessary
> >> processing), so that the new instance `inherits' from the old one.
>
> how do I do this? This is not for a class (I mean, it *IS* for a CLOS
> class, but not for a school class :-). Could you please give a code
> snippet?
I was assuming:
(define-condition problem () ())
(define-condition serious-problem (problem) ())
and I was suggesting you could do
(define-condition escalated-problem (serious-problem)
((original-problem :initarg :original-problem :accessor original-problem)))
and do
(handler-bind ((problem #'(lambda (c)
(when (some-circumstance-of c)
(signal 'escalated-problem
:original-problem c)))))
...)
or some such thing. I think in my message I had done this in shorthand
by assuming that serious-problem could be made to have this extra slot,
but maybe it's easier to see with this elaborated form.
In general, I strongly recommend this over any use of change-class
or any attempt to change slot values in the condition.
On the other hand, it's just a little suspect to make seriousness be a
property of the condition. The built-in serious condition is used to
"solve" (and I use the term very lightly) the problem that you don't
have a way of inquiring of a condition whether the absolute default
behavior will be "entry to the debugger" or "no action". That's a
very critical thing to know. But serious-condition-ness is a bad way
to communicate the information, even if it's built into the language.
This is something I knew was a mess when I administered the addition
of conditions to CL, and I expected a lot more people to complain
about than actually did. I *assume* people really do run into lots of
problems that they don't report and perhaps don't even articulate or
recognize per se. There are not very good answers to this. I vaguely
recall we did better about it in the ISLISP error system, actually.
If I was more ambitious, I'd go look it up. Maybe another evening.