IGNORE-ERRORSERRSET (as on p428 of CLtL)
Introduce a new macro called IGNORE-ERRORS with the syntax
(IGNORE-ERRORS {form}*) IGNORE-ERRORS executes the given forms in order from left to right, returning all the values returned by the last form (or NIL if there are no forms).
If an error occurs while executing the forms, however, no error message is printed; instead control is silently transfered to the IGNORE-ERRORS form, which immediately returns a principal value of NIL. (The return value convention for any other values besides the principal return value in the case of an error is expressly left undefined in order to leave room for the full error proposal to attach a useful meaning.)
CL spec.
The baroque return value convention used by Maclisp's ERRSET special form (mentioned on p428 of CLtL) does not extend gracefully to situations multiple values.
ERRSET, IGNORE-ERRORS, or something similar in some private package.IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS) (LET ((TAG (GENSYM))) `(BLOCK ,TAG (ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL) NIL)))
IGNORE-ERRORS and more. In case of delays or problems in the acceptance of the spec, applications developers will not have to worry that they'll end up with no way to trap errors.KMP thinks that in spite of the perceived optimism about the emerging error proposal, it's wise to have a safe and credible interim position. Masinter wonders why KMP isn't spending more time on the error proposal.
The cleanup committee endorses this extension. TITANTITAN TIMESROMAN ªêL"æIj$ é~[Tzº*start* 00473 00024 US Date: 1 Jun 87 18:32 PDT From: Pavel.pa Subject: Re: IGNORE-ERRORS (Version 4) In-reply-to: Masinter.pa's message of 29 May 87 21:20 PDT To: Masinter.pa
Typo in the proposal:
``An error proposal is in the works which will offer IGNORE-ERRORS and more.'' should be ``An error proposal is in the works that will offer IGNORE-ERRORS and more.'' GACHA
TIMESROMAN ´JIYzº*start* 02802 00024 US Return-Path: <KMP@STONY-BROOK.SCRC.Symbolics.COM> Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by Xerox.COM ; 01 JUN 87 20:46:23 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161244; Mon 1-Jun-87 23:44:37 EDT Date: Mon, 1 Jun 87 23:46 EDT From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: IGNORE-ERRORS (Version 4) To: Masinter.pa cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <870529-212051-1278@Xerox> Message-ID: <870601234627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 29 May 87 21:20 PDT From: Masinter.pa@Xerox.COM
... Issue: IGNORE-ERRORS ...
KMP thinks that in spite of the perceived optimism about the emerging error proposal, it's wise to have a safe and credible interim position. Masinter wonders why KMP isn't spending more time on the error proposal. ...
I'd like to encourage you to remove this somewhat random comment, which may be viewed by outsiders as being more critical than you hopefully meant. In fact, KMP is spending a -lot- of time on the error proposal.
The problem is that KMP has what he thinks is a clear understanding both of the length of time it takes to get things of that size through a political mechanism such as X3J13 even under ordinary circumstances, and is -very- leary about potential last-minute snags due to the emergence of CLOS in parallel and the fact that people will likely want last-minute "small changes" to make it take more advantage of CLOS.
The presence of this item as a place-holder while all the business of acceptance is in progress is particularly important to me. The more vendors who provide this as a private extension in the very near term, the fewer utterly random interfaces they'll conjure instead. Like it or not, existing code has to interface to the private extensions until this standard is marked approved, but we can do a lot to improve quality of life by at least hinting that this is coming. In Macsyma, there's a definition of IGNORE-ERRORS that does:
#+LispM `(CONDITION-CASE (-ERROR-) (VALUES (PROGN ,@FORMS) NIL) (ZL:SYS:ERROR (VALUES NIL -ERROR-))) #+(OR ...other-systems...) `(LET ((RESULT (ERRSET (PROGN ,@FORMS) NIL))) (IF RESULT (VALUES (CAR RESULT) NIL) (VALUES NIL T))) #+(OR ...more-other-systems...) ...etc.
Each new case added requires careful study of the host error system to figure out how to attach an IGNORE-ERRORS. If everyone had the idea that at least IGNORE-ERRORS was worth latching onto, I think they'd at least do that even if they weren't sure of the rest of the emerging error system, and I think the resulting convergence would be very useful.