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

AI.Repository@cs.cmu.edu