91 lines
5.2 KiB
HTML
91 lines
5.2 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
|
||
|
|
<!Converted with LaTeX2HTML 0.6.5 (Tue Nov 15 1994) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds >
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>29.3.2. Trapping Errors</TITLE>
|
||
|
|
</HEAD>
|
||
|
|
<BODY>
|
||
|
|
<meta name="description" value=" Trapping Errors">
|
||
|
|
<meta name="keywords" value="clm">
|
||
|
|
<meta name="resource-type" value="document">
|
||
|
|
<meta name="distribution" value="global">
|
||
|
|
<P>
|
||
|
|
<b>Common Lisp the Language, 2nd Edition</b>
|
||
|
|
<BR> <HR><A NAME=tex2html5659 HREF="node318.html"><IMG ALIGN=BOTTOM ALT="next" SRC="icons/next_motif.gif"></A> <A NAME=tex2html5657 HREF="node315.html"><IMG ALIGN=BOTTOM ALT="up" SRC="icons/up_motif.gif"></A> <A NAME=tex2html5651 HREF="node316.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="icons/previous_motif.gif"></A> <A NAME=tex2html5661 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="icons/contents_motif.gif"></A> <A NAME=tex2html5662 HREF="index.html"><IMG ALIGN=BOTTOM ALT="index" SRC="icons/index_motif.gif"></A> <BR>
|
||
|
|
<B> Next:</B> <A NAME=tex2html5660 HREF="node318.html"> Handling Conditions</A>
|
||
|
|
<B>Up:</B> <A NAME=tex2html5658 HREF="node315.html"> Survey of Concepts</A>
|
||
|
|
<B> Previous:</B> <A NAME=tex2html5652 HREF="node316.html"> Signaling Errors</A>
|
||
|
|
<HR> <P>
|
||
|
|
<H2><A NAME=SECTION003332000000000000000>29.3.2. Trapping Errors</A></H2>
|
||
|
|
<P>
|
||
|
|
<img align=bottom alt="change_begin" src="gif/change_begin.gif"><br>
|
||
|
|
<A NAME=TRAPPINGERRORS>By</A>
|
||
|
|
default, a call to <tt>error</tt> 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 <tt>ignore-errors</tt>.
|
||
|
|
In the normal situation, forms in the body of <tt>ignore-errors</tt> are evaluated
|
||
|
|
sequentially and the last value is returned. If a condition of type <tt>error</tt> is
|
||
|
|
signaled, <tt>ignore-errors</tt> immediately returns two values, namely <tt>nil</tt> and the
|
||
|
|
condition that was signaled; the debugger is not entered and no error
|
||
|
|
message is printed. For example:
|
||
|
|
<P><pre>
|
||
|
|
Lisp> (setq filename "nosuchfile")
|
||
|
|
=> "nosuchfile"
|
||
|
|
Lisp> (ignore-errors (open filename :direction :input))
|
||
|
|
=> NIL and #<FILE-ERROR 3437523>
|
||
|
|
</pre><P>
|
||
|
|
The second return value is an object that represents the kind of error. This
|
||
|
|
is explained in greater detail in section <A HREF="node319.html#OBJECT0RIENTEDBASIS">29.3.4</A>.
|
||
|
|
<P>
|
||
|
|
In many cases, however, <tt>ignore-errors</tt> 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 <tt>ignore-errors</tt> 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.
|
||
|
|
<P>
|
||
|
|
<tt>ignore-errors</tt> is a useful special case built from a more general facility,
|
||
|
|
<tt>handler-case</tt>, 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 <tt>ignore-errors</tt> above is achieved in the following example:
|
||
|
|
<P><pre>
|
||
|
|
Lisp> (setq filename "nosuchfile")
|
||
|
|
=> "nosuchfile"
|
||
|
|
Lisp> (handler-case (open filename :direction :input)
|
||
|
|
(error (condition)
|
||
|
|
(values nil condition)))
|
||
|
|
=> NIL and #<FILE-ERROR 3437525>
|
||
|
|
</pre><P>
|
||
|
|
However, using <tt>handler-case</tt>, 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:
|
||
|
|
<P><pre>
|
||
|
|
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>
|
||
|
|
</pre><P>
|
||
|
|
<br><img align=bottom alt="change_end" src="gif/change_end.gif">
|
||
|
|
<P>
|
||
|
|
<BR> <HR><A NAME=tex2html5659 HREF="node318.html"><IMG ALIGN=BOTTOM ALT="next" SRC="icons/next_motif.gif"></A> <A NAME=tex2html5657 HREF="node315.html"><IMG ALIGN=BOTTOM ALT="up" SRC="icons/up_motif.gif"></A> <A NAME=tex2html5651 HREF="node316.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="icons/previous_motif.gif"></A> <A NAME=tex2html5661 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="contents" SRC="icons/contents_motif.gif"></A> <A NAME=tex2html5662 HREF="index.html"><IMG ALIGN=BOTTOM ALT="index" SRC="icons/index_motif.gif"></A> <BR>
|
||
|
|
<B> Next:</B> <A NAME=tex2html5660 HREF="node318.html"> Handling Conditions</A>
|
||
|
|
<B>Up:</B> <A NAME=tex2html5658 HREF="node315.html"> Survey of Concepts</A>
|
||
|
|
<B> Previous:</B> <A NAME=tex2html5652 HREF="node316.html"> Signaling Errors</A>
|
||
|
|
<HR> <P>
|
||
|
|
<HR>
|
||
|
|
<P><ADDRESS>
|
||
|
|
AI.Repository@cs.cmu.edu
|
||
|
|
</ADDRESS>
|
||
|
|
</BODY>
|