IGNORE-ERRORS (Version 4)

[Masinter.pa@Xerox.COM]

Status:   Ready for release? [Use ballot]

Issue:        IGNORE-ERRORS
References:   p428
Category:     ENHANCEMENT
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

Problem Description:

Common Lisp has no way to trap an error inhibiting entry to the debugger.

Proposal (IGNORE-ERRORS:INTERIM):

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 {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.)

Rationale:

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
values.

Current Practice:

Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.

Adoption Cost:

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)))
      `(BLOCK ,TAG 
	 (ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
	 NIL)))

Benefits:

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
errors.

Conversion Cost:

User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.

Aesthetics:

This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.

Discussion:

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.