[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Error Proposal #5: difficulties and suggestions
- To: KMP@SCRC-STONY-BROOK.ARPA
- Subject: Re: Error Proposal #5: difficulties and suggestions
- From: Daniels.pa@Xerox.COM
- Date: 21 Apr 86 14:57 PST
- Cc: Daniels.pa@Xerox.COM, CL-Error-Handling@SU-AI.ARPA
- In-reply-to: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>'s message of Fri, 18 Apr 86 01:27 EST
"(EVAL `(PROCEED-CASE ..."
Ugh, indeed. Yes, this will certainly get around the problem, though not
very elegantly. I'm not too happy about having this spurious proceed
case sitting around if you break while in INVOKE-DEFAULTED-PROCEED-CASE,
but it will do until we come up with the "right" way to fix it. I still
think the right fix is to have a proceed function take an optional
proceed-case argument. I just haven't been able to find any good place
to put it. The obvious place is after the implicit condition argument.
The problem I have with that is that almost all callers of proceed
functions will be condition handlers, and it seems like a nuisance to
have to always put in an extra NIL, like in (USE-VALUE CONDITION NIL
NEW-VALUE).
"...and hence allow (SIGNAL 'a-serious-condition) to not enter
the debugger"
I think you misread what I wrote. I was suggesting that SIGNAL check the
type of the condition it signalled and go to the debugger if it was a
SERIOUS-CONDITION instead of depending on a default handler to do it.
Then there wouldn't be any fundamental problem with allowing a user to
change a default handler on the fly. Anyway, yes, I'm suggesting that we
not depend on system-defined default handlers to implement the semantics
of SERIOUS-CONDITION.
"In any case, it should probably go out of its way to mention that
it's [using the same proceed-case name] ok"
Clarifications like that are always good. Another fine point that might
be useful to mention is the difference between :TEST TRUE and :CONDITION
CONDITION. The first is more general than the second because the proceed
case will be visible even if a NIL is passed to the proceed function
instead of a condition. This becomes important for things like ABORT,
which will usually not be given any arguments.
In PROCEED-CASE, under the description of :REPORT, you have CONDITION
being bound by default. Shouldn't the variable be something like
PROCEED-CASE, since that's what's being bound rather than a condition?
-- Andy. --