Errors

[Jonathan A. Rees <JAR at MIT-MC>]

From:     Date:
Date: Thu, 7 Nov 80 19:19:56 GMT
Original-Date: 07/11/80 15:19:56 EDT
Subject:
    From: EB at MIT-AI
    To:   (BUG LISP)
    cc:   JAR
        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.
							    Wouldn't
    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.)