[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IGNORE-ERRORS (Version 4)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: IGNORE-ERRORS (Version 4)
- From: Masinter.pa@Xerox.COM
- Date: 29 May 87 21:20 PDT
- Cc: Masinter.pa@Xerox.COM
Status: Ready for release? [Use ballot]
Edit history: Revision 1 by KMP 02/26/87,
Revision 2 by KMP 02/26/87 (fixed typo in sample code),
Revision 3 by KMP 03/11/87 (change to 2nd return value).
Revision 4 by Masinter 29-May-87 minor formatting
Common Lisp has no way to trap an error inhibiting entry to the debugger.
Remove the apology for the absence of ERRSET (as on p428 of CLtL)
Introduce a new macro called IGNORE-ERRORS with the syntax
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.)
It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next 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
Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.
We believe this is not difficult to implement in any current implementation.
E.g., IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS)
(LET ((TAG (GENSYM)))
(ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
An error proposal is in the works which will offer 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
User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.
This primitive is simple, clean, easily learnable, and hopefully very
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.