upgrading errors 
Author Message
 upgrading errors

Quote:


> >>>> On the subject of "Re: upgrading errors"
> >>>> Sent on Sun, 2 May 1999 11:21:06 +0300

>  >> 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 de{*filter*}" 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.



Fri, 19 Oct 2001 03:00:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Upgrade Errors

2. Clipper 5.2 to 5.2e Upgrade error

3. Dictionary Editor Error After Upgrading to 5.5D

4. Error installing c5.5 upgrades

5. Error after upgrade from C55 (D) to C55 (H)

6. upgrade cw1500 to cw1501 gives bind error

7. Help-Report Gen Error since upgrade to V2

8. CW2002.1 - Error (33) in code that worked fine before upgrading from CW2001

9. Unrecoverable error 650 when upgrading PC

10. Errors are coming in IVI engine while upgrading LV6.1

11. Call Library Function Error after upgrading to Win2000

12. Error installing PL/I Upgrade 2.1.7 on Win NT

 

 
Powered by phpBB® Forum Software