[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: EB at MIT-AI
- Subject: Errors
- From: Jonathan A. Rees <JAR at MIT-MC>
- Date: Mon, 14 Jul 80 18:28:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 14 July 1980 14:28-EDT
Date: Thu, 7 Nov 80 19:19:56 GMT
Original-Date: 07/11/80 15:19:56 EDT
From: EB at MIT-AI
To: (BUG LISP)
Date: 10 JUL 1980 1940-EDT
From: JAR at MIT-MC (Jonathan A. Rees)
The reason for this is that ERROR was called with no
interrupt channel argument while *RSET was (). That is a RUDE thing
for ANY error detection code to do.
Why? Seems controversial to me. If you don't want errors like that to
go immediately to top level, don't run with *RSET nil.
Don't jump to the conclusion that I was running with *RSET nil. I hardly
ever do, and wasn't doing so in this case. I do, however, have to use
Jonl's system code which has the nasty habit of BINDING *RSET to nil within
certain functions, like the one that caused my grief.
giving an interrupt channel argument typically make the error
correctable, while the whole point of using ERROR might be that a
semantically uncorrectable error has occurred?
I had no intention of correcting the error! I only wanted to look at my
execution context at the point where the error occurred! And according
to your argument, the right thing to do would be to do a (QUIT), since
throwing to top level is itself a form of "recovery."
Also, note that errors
written as calls to FERROR will give no interrupt channel argument
(unless I am mistaken); does that mean that FERROR is a RUDE function
for ANY error detection code to call?
No, it means that there's some bug in the implementation of FERROR you refer
to. (What version is that, btw? The kludgey version defined by LSPSRC;
EXTEND/EXTMAC - not that I want to recommend or defend it - at least uses
the FAIL-ACT channel by default, prior to bombing out completely.)