[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Various Decisions
- To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Various Decisions
- From: kempf%hplabsz@hplabs.HP.COM
- Date: Tue, 29 Sep 87 16:11:46 MST
- Cc: Pavel.pa@Xerox.COM, Common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Your message of Tue, 29 Sep 87 17:36:00 -0400. <870929173603.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
> Date: Tue, 29 Sep 87 12:05:58 PDT
> From: Pavel.pa@Xerox.COM
> Why are folks so opposed to using the error system instead of this
> NEXT-METHOD function? It seems the obvious thing, leading to more
> readable code with a clearer intent.
> Note that condition h> andlers have dynamic rather than lexical "scope"
> (or whatever word you want to use for the portion of program that they
> affect). Thus a HANDLER-CASE around a CALL-NEXT-METHOD might actually
> intercept some inner CALL-NEXT-METHOD in some inner, nested method.
> There's no way to turn off the handler as soon as the CALL-NEXT-METHOD
> has succeeded in passing control to the next method.
Well, my reading of the Pitman error proposal (admittedly dated 1985) is that
something like this should work:
(catch-condition no-next-method &body (call-next-method))
should work. If there is no next method, then NIL will be returned as
the first value of the form, and the condition "object" as the second.
Of course, the condition NO-NEXT-METHOD must first be defined.