Common Lisp the Language, 2nd Edition

Next: Handling Conditions Up: Survey of Concepts Previous: Signaling Errors

## 29.3.2. Trapping Errors

By default, a call to `error` will force entry into the debugger. You can override that behavior in a variety of ways. The simplest (and most blunt) tool for inhibiting entry to the debugger on an error is to use `ignore-errors`. In the normal situation, forms in the body of `ignore-errors` are evaluated sequentially and the last value is returned. If a condition of type `error` is signaled, `ignore-errors` immediately returns two values, namely `nil` and the condition that was signaled; the debugger is not entered and no error message is printed. For example:

    Lisp> (setq filename "nosuchfile")
     => "nosuchfile"
    Lisp> (ignore-errors (open filename :direction :input))
     => NIL and #<FILE-ERROR 3437523>

The second return value is an object that represents the kind of error. This is explained in greater detail in section 29.3.4.

In many cases, however, `ignore-errors` is not desirable because it deals with too many kinds of errors. Contrary to the belief of some, a program that does not enter the debugger is not necessarily better than one that does. Excessive use of `ignore-errors` may keep the program out of the debugger, but it may not increase the program's reliability, because the program may continue to run after encountering errors other than those you meant to work past. In general, it is better to attempt to deal only with the particular kinds of errors that you believe could legitimately happen. That way, if an unexpected error comes along, you will still find out about it.

`ignore-errors` is a useful special case built from a more general facility, `handler-case`, that allows the programmer to deal with particular kinds of conditions (including non-error conditions) without affecting what happens when other kinds of conditions are signaled. For example, an effect equivalent to that of `ignore-errors` above is achieved in the following example:

    Lisp> (setq filename "nosuchfile")
     => "nosuchfile"
    Lisp> (handler-case (open filename :direction :input)
            (error (condition)
              (values nil condition)))
     => NIL and #<FILE-ERROR 3437525>

However, using `handler-case`, one can indicate a more specific condition type than just ``error.'' Condition types are explained in detail later, but the syntax looks roughly like the following:

    Lisp> (makunbound 'filename)
     => FILENAME
    Lisp> (handler-case (open filename :direction :input)
            (file-error (condition)
              (values nil condition)))
    Error: The variable FILENAME is unbound.
    To continue, type :CONTINUE followed by an option number:
     1: Retry getting the value of FILENAME.
     2: Specify a value of FILENAME to use this time.
     3: Specify a value of FILENAME to store and use.
     4: Return to Lisp Toplevel.
    Debug>

Next: Handling Conditions Up: Survey of Concepts Previous: Signaling Errors