Commit | Line | Data |
---|---|---|
83ac6b45 RS |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Emacs Lisp Reference Manual. | |
b3d90e46 GM |
3 | @c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2001, 2002, |
4 | @c 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc. | |
83ac6b45 RS |
5 | @c See the file elisp.texi for copying conditions. |
6 | @setfilename ../info/control | |
7 | @node Control Structures, Variables, Evaluation, Top | |
8 | @chapter Control Structures | |
9 | @cindex special forms for control structures | |
10 | @cindex control structures | |
11 | ||
12 | A Lisp program consists of expressions or @dfn{forms} (@pxref{Forms}). | |
3f63de1e | 13 | We control the order of execution of these forms by enclosing them in |
83ac6b45 | 14 | @dfn{control structures}. Control structures are special forms which |
3e099569 RS |
15 | control when, whether, or how many times to execute the forms they |
16 | contain. | |
83ac6b45 | 17 | |
3e099569 | 18 | The simplest order of execution is sequential execution: first form |
83ac6b45 RS |
19 | @var{a}, then form @var{b}, and so on. This is what happens when you |
20 | write several forms in succession in the body of a function, or at top | |
3e099569 RS |
21 | level in a file of Lisp code---the forms are executed in the order |
22 | written. We call this @dfn{textual order}. For example, if a function | |
23 | body consists of two forms @var{a} and @var{b}, evaluation of the | |
8241495d RS |
24 | function evaluates first @var{a} and then @var{b}. The result of |
25 | evaluating @var{b} becomes the value of the function. | |
3e099569 RS |
26 | |
27 | Explicit control structures make possible an order of execution other | |
28 | than sequential. | |
83ac6b45 RS |
29 | |
30 | Emacs Lisp provides several kinds of control structure, including | |
3e099569 RS |
31 | other varieties of sequencing, conditionals, iteration, and (controlled) |
32 | jumps---all discussed below. The built-in control structures are | |
33 | special forms since their subforms are not necessarily evaluated or not | |
34 | evaluated sequentially. You can use macros to define your own control | |
35 | structure constructs (@pxref{Macros}). | |
83ac6b45 RS |
36 | |
37 | @menu | |
38 | * Sequencing:: Evaluation in textual order. | |
f9f59935 | 39 | * Conditionals:: @code{if}, @code{cond}, @code{when}, @code{unless}. |
83ac6b45 RS |
40 | * Combining Conditions:: @code{and}, @code{or}, @code{not}. |
41 | * Iteration:: @code{while} loops. | |
42 | * Nonlocal Exits:: Jumping out of a sequence. | |
43 | @end menu | |
44 | ||
45 | @node Sequencing | |
46 | @section Sequencing | |
47 | ||
3e099569 RS |
48 | Evaluating forms in the order they appear is the most common way |
49 | control passes from one form to another. In some contexts, such as in a | |
50 | function body, this happens automatically. Elsewhere you must use a | |
51 | control structure construct to do this: @code{progn}, the simplest | |
52 | control construct of Lisp. | |
83ac6b45 RS |
53 | |
54 | A @code{progn} special form looks like this: | |
55 | ||
56 | @example | |
57 | @group | |
58 | (progn @var{a} @var{b} @var{c} @dots{}) | |
59 | @end group | |
60 | @end example | |
61 | ||
62 | @noindent | |
3f63de1e | 63 | and it says to execute the forms @var{a}, @var{b}, @var{c}, and so on, in |
8241495d | 64 | that order. These forms are called the @dfn{body} of the @code{progn} form. |
83ac6b45 | 65 | The value of the last form in the body becomes the value of the entire |
8241495d | 66 | @code{progn}. @code{(progn)} returns @code{nil}. |
83ac6b45 RS |
67 | |
68 | @cindex implicit @code{progn} | |
69 | In the early days of Lisp, @code{progn} was the only way to execute | |
70 | two or more forms in succession and use the value of the last of them. | |
71 | But programmers found they often needed to use a @code{progn} in the | |
72 | body of a function, where (at that time) only one form was allowed. So | |
73 | the body of a function was made into an ``implicit @code{progn}'': | |
74 | several forms are allowed just as in the body of an actual @code{progn}. | |
75 | Many other control structures likewise contain an implicit @code{progn}. | |
8241495d RS |
76 | As a result, @code{progn} is not used as much as it was many years ago. |
77 | It is needed now most often inside an @code{unwind-protect}, @code{and}, | |
3e099569 | 78 | @code{or}, or in the @var{then}-part of an @code{if}. |
83ac6b45 RS |
79 | |
80 | @defspec progn forms@dots{} | |
81 | This special form evaluates all of the @var{forms}, in textual | |
82 | order, returning the result of the final form. | |
83 | ||
84 | @example | |
85 | @group | |
86 | (progn (print "The first form") | |
87 | (print "The second form") | |
88 | (print "The third form")) | |
89 | @print{} "The first form" | |
90 | @print{} "The second form" | |
91 | @print{} "The third form" | |
92 | @result{} "The third form" | |
93 | @end group | |
94 | @end example | |
95 | @end defspec | |
96 | ||
97 | Two other control constructs likewise evaluate a series of forms but return | |
98 | a different value: | |
99 | ||
100 | @defspec prog1 form1 forms@dots{} | |
101 | This special form evaluates @var{form1} and all of the @var{forms}, in | |
102 | textual order, returning the result of @var{form1}. | |
103 | ||
104 | @example | |
105 | @group | |
106 | (prog1 (print "The first form") | |
107 | (print "The second form") | |
108 | (print "The third form")) | |
109 | @print{} "The first form" | |
110 | @print{} "The second form" | |
111 | @print{} "The third form" | |
112 | @result{} "The first form" | |
113 | @end group | |
114 | @end example | |
115 | ||
116 | Here is a way to remove the first element from a list in the variable | |
117 | @code{x}, then return the value of that former element: | |
118 | ||
119 | @example | |
120 | (prog1 (car x) (setq x (cdr x))) | |
121 | @end example | |
122 | @end defspec | |
123 | ||
124 | @defspec prog2 form1 form2 forms@dots{} | |
125 | This special form evaluates @var{form1}, @var{form2}, and all of the | |
126 | following @var{forms}, in textual order, returning the result of | |
127 | @var{form2}. | |
128 | ||
129 | @example | |
130 | @group | |
131 | (prog2 (print "The first form") | |
132 | (print "The second form") | |
133 | (print "The third form")) | |
134 | @print{} "The first form" | |
135 | @print{} "The second form" | |
136 | @print{} "The third form" | |
137 | @result{} "The second form" | |
138 | @end group | |
139 | @end example | |
140 | @end defspec | |
141 | ||
142 | @node Conditionals | |
143 | @section Conditionals | |
144 | @cindex conditional evaluation | |
145 | ||
146 | Conditional control structures choose among alternatives. Emacs Lisp | |
26eb64a9 RS |
147 | has four conditional forms: @code{if}, which is much the same as in |
148 | other languages; @code{when} and @code{unless}, which are variants of | |
149 | @code{if}; and @code{cond}, which is a generalized case statement. | |
83ac6b45 RS |
150 | |
151 | @defspec if condition then-form else-forms@dots{} | |
152 | @code{if} chooses between the @var{then-form} and the @var{else-forms} | |
153 | based on the value of @var{condition}. If the evaluated @var{condition} is | |
154 | non-@code{nil}, @var{then-form} is evaluated and the result returned. | |
155 | Otherwise, the @var{else-forms} are evaluated in textual order, and the | |
156 | value of the last one is returned. (The @var{else} part of @code{if} is | |
177c0ea7 | 157 | an example of an implicit @code{progn}. @xref{Sequencing}.) |
83ac6b45 RS |
158 | |
159 | If @var{condition} has the value @code{nil}, and no @var{else-forms} are | |
160 | given, @code{if} returns @code{nil}. | |
161 | ||
3e099569 | 162 | @code{if} is a special form because the branch that is not selected is |
83ac6b45 RS |
163 | never evaluated---it is ignored. Thus, in the example below, |
164 | @code{true} is not printed because @code{print} is never called. | |
165 | ||
166 | @example | |
167 | @group | |
177c0ea7 JB |
168 | (if nil |
169 | (print 'true) | |
83ac6b45 RS |
170 | 'very-false) |
171 | @result{} very-false | |
172 | @end group | |
173 | @end example | |
174 | @end defspec | |
26eb64a9 | 175 | |
f9f59935 | 176 | @defmac when condition then-forms@dots{} |
26eb64a9 RS |
177 | This is a variant of @code{if} where there are no @var{else-forms}, |
178 | and possibly several @var{then-forms}. In particular, | |
179 | ||
180 | @example | |
181 | (when @var{condition} @var{a} @var{b} @var{c}) | |
182 | @end example | |
183 | ||
184 | @noindent | |
185 | is entirely equivalent to | |
186 | ||
187 | @example | |
188 | (if @var{condition} (progn @var{a} @var{b} @var{c}) nil) | |
189 | @end example | |
f9f59935 | 190 | @end defmac |
26eb64a9 | 191 | |
f9f59935 | 192 | @defmac unless condition forms@dots{} |
26eb64a9 RS |
193 | This is a variant of @code{if} where there is no @var{then-form}: |
194 | ||
195 | @example | |
196 | (unless @var{condition} @var{a} @var{b} @var{c}) | |
197 | @end example | |
198 | ||
199 | @noindent | |
200 | is entirely equivalent to | |
201 | ||
202 | @example | |
203 | (if @var{condition} nil | |
204 | @var{a} @var{b} @var{c}) | |
205 | @end example | |
f9f59935 | 206 | @end defmac |
83ac6b45 RS |
207 | |
208 | @defspec cond clause@dots{} | |
209 | @code{cond} chooses among an arbitrary number of alternatives. Each | |
210 | @var{clause} in the @code{cond} must be a list. The @sc{car} of this | |
211 | list is the @var{condition}; the remaining elements, if any, the | |
212 | @var{body-forms}. Thus, a clause looks like this: | |
213 | ||
214 | @example | |
215 | (@var{condition} @var{body-forms}@dots{}) | |
216 | @end example | |
217 | ||
218 | @code{cond} tries the clauses in textual order, by evaluating the | |
219 | @var{condition} of each clause. If the value of @var{condition} is | |
220 | non-@code{nil}, the clause ``succeeds''; then @code{cond} evaluates its | |
221 | @var{body-forms}, and the value of the last of @var{body-forms} becomes | |
222 | the value of the @code{cond}. The remaining clauses are ignored. | |
223 | ||
827b7ee7 | 224 | If the value of @var{condition} is @code{nil}, the clause ``fails,'' so |
83ac6b45 RS |
225 | the @code{cond} moves on to the following clause, trying its |
226 | @var{condition}. | |
227 | ||
228 | If every @var{condition} evaluates to @code{nil}, so that every clause | |
229 | fails, @code{cond} returns @code{nil}. | |
230 | ||
231 | A clause may also look like this: | |
232 | ||
233 | @example | |
234 | (@var{condition}) | |
235 | @end example | |
236 | ||
237 | @noindent | |
238 | Then, if @var{condition} is non-@code{nil} when tested, the value of | |
239 | @var{condition} becomes the value of the @code{cond} form. | |
240 | ||
241 | The following example has four clauses, which test for the cases where | |
242 | the value of @code{x} is a number, string, buffer and symbol, | |
243 | respectively: | |
244 | ||
245 | @example | |
246 | @group | |
247 | (cond ((numberp x) x) | |
248 | ((stringp x) x) | |
249 | ((bufferp x) | |
250 | (setq temporary-hack x) ; @r{multiple body-forms} | |
251 | (buffer-name x)) ; @r{in one clause} | |
252 | ((symbolp x) (symbol-value x))) | |
253 | @end group | |
254 | @end example | |
255 | ||
256 | Often we want to execute the last clause whenever none of the previous | |
257 | clauses was successful. To do this, we use @code{t} as the | |
258 | @var{condition} of the last clause, like this: @code{(t | |
259 | @var{body-forms})}. The form @code{t} evaluates to @code{t}, which is | |
260 | never @code{nil}, so this clause never fails, provided the @code{cond} | |
261 | gets to it at all. | |
262 | ||
177c0ea7 | 263 | For example, |
83ac6b45 RS |
264 | |
265 | @example | |
266 | @group | |
8241495d | 267 | (setq a 5) |
3e099569 | 268 | (cond ((eq a 'hack) 'foo) |
83ac6b45 RS |
269 | (t "default")) |
270 | @result{} "default" | |
271 | @end group | |
272 | @end example | |
273 | ||
274 | @noindent | |
8241495d RS |
275 | This @code{cond} expression returns @code{foo} if the value of @code{a} |
276 | is @code{hack}, and returns the string @code{"default"} otherwise. | |
83ac6b45 RS |
277 | @end defspec |
278 | ||
3e099569 RS |
279 | Any conditional construct can be expressed with @code{cond} or with |
280 | @code{if}. Therefore, the choice between them is a matter of style. | |
281 | For example: | |
83ac6b45 RS |
282 | |
283 | @example | |
284 | @group | |
285 | (if @var{a} @var{b} @var{c}) | |
286 | @equiv{} | |
287 | (cond (@var{a} @var{b}) (t @var{c})) | |
288 | @end group | |
289 | @end example | |
290 | ||
291 | @node Combining Conditions | |
292 | @section Constructs for Combining Conditions | |
293 | ||
294 | This section describes three constructs that are often used together | |
295 | with @code{if} and @code{cond} to express complicated conditions. The | |
296 | constructs @code{and} and @code{or} can also be used individually as | |
297 | kinds of multiple conditional constructs. | |
298 | ||
299 | @defun not condition | |
300 | This function tests for the falsehood of @var{condition}. It returns | |
301 | @code{t} if @var{condition} is @code{nil}, and @code{nil} otherwise. | |
302 | The function @code{not} is identical to @code{null}, and we recommend | |
303 | using the name @code{null} if you are testing for an empty list. | |
304 | @end defun | |
305 | ||
306 | @defspec and conditions@dots{} | |
307 | The @code{and} special form tests whether all the @var{conditions} are | |
308 | true. It works by evaluating the @var{conditions} one by one in the | |
309 | order written. | |
310 | ||
311 | If any of the @var{conditions} evaluates to @code{nil}, then the result | |
312 | of the @code{and} must be @code{nil} regardless of the remaining | |
8241495d RS |
313 | @var{conditions}; so @code{and} returns @code{nil} right away, ignoring |
314 | the remaining @var{conditions}. | |
83ac6b45 RS |
315 | |
316 | If all the @var{conditions} turn out non-@code{nil}, then the value of | |
8241495d RS |
317 | the last of them becomes the value of the @code{and} form. Just |
318 | @code{(and)}, with no @var{conditions}, returns @code{t}, appropriate | |
319 | because all the @var{conditions} turned out non-@code{nil}. (Think | |
320 | about it; which one did not?) | |
83ac6b45 RS |
321 | |
322 | Here is an example. The first condition returns the integer 1, which is | |
323 | not @code{nil}. Similarly, the second condition returns the integer 2, | |
324 | which is not @code{nil}. The third condition is @code{nil}, so the | |
325 | remaining condition is never evaluated. | |
326 | ||
327 | @example | |
328 | @group | |
329 | (and (print 1) (print 2) nil (print 3)) | |
330 | @print{} 1 | |
331 | @print{} 2 | |
332 | @result{} nil | |
333 | @end group | |
334 | @end example | |
335 | ||
336 | Here is a more realistic example of using @code{and}: | |
337 | ||
338 | @example | |
339 | @group | |
340 | (if (and (consp foo) (eq (car foo) 'x)) | |
341 | (message "foo is a list starting with x")) | |
342 | @end group | |
343 | @end example | |
344 | ||
345 | @noindent | |
346 | Note that @code{(car foo)} is not executed if @code{(consp foo)} returns | |
347 | @code{nil}, thus avoiding an error. | |
348 | ||
85831f9a RS |
349 | @code{and} expressions can also be written using either @code{if} or |
350 | @code{cond}. Here's how: | |
83ac6b45 RS |
351 | |
352 | @example | |
353 | @group | |
354 | (and @var{arg1} @var{arg2} @var{arg3}) | |
355 | @equiv{} | |
356 | (if @var{arg1} (if @var{arg2} @var{arg3})) | |
357 | @equiv{} | |
358 | (cond (@var{arg1} (cond (@var{arg2} @var{arg3})))) | |
359 | @end group | |
360 | @end example | |
361 | @end defspec | |
362 | ||
363 | @defspec or conditions@dots{} | |
364 | The @code{or} special form tests whether at least one of the | |
365 | @var{conditions} is true. It works by evaluating all the | |
366 | @var{conditions} one by one in the order written. | |
367 | ||
368 | If any of the @var{conditions} evaluates to a non-@code{nil} value, then | |
369 | the result of the @code{or} must be non-@code{nil}; so @code{or} returns | |
370 | right away, ignoring the remaining @var{conditions}. The value it | |
371 | returns is the non-@code{nil} value of the condition just evaluated. | |
372 | ||
373 | If all the @var{conditions} turn out @code{nil}, then the @code{or} | |
8241495d RS |
374 | expression returns @code{nil}. Just @code{(or)}, with no |
375 | @var{conditions}, returns @code{nil}, appropriate because all the | |
376 | @var{conditions} turned out @code{nil}. (Think about it; which one | |
377 | did not?) | |
83ac6b45 | 378 | |
177c0ea7 | 379 | For example, this expression tests whether @code{x} is either |
8241495d | 380 | @code{nil} or the integer zero: |
83ac6b45 RS |
381 | |
382 | @example | |
383 | (or (eq x nil) (eq x 0)) | |
384 | @end example | |
385 | ||
386 | Like the @code{and} construct, @code{or} can be written in terms of | |
387 | @code{cond}. For example: | |
388 | ||
389 | @example | |
390 | @group | |
391 | (or @var{arg1} @var{arg2} @var{arg3}) | |
392 | @equiv{} | |
393 | (cond (@var{arg1}) | |
394 | (@var{arg2}) | |
395 | (@var{arg3})) | |
396 | @end group | |
397 | @end example | |
398 | ||
399 | You could almost write @code{or} in terms of @code{if}, but not quite: | |
400 | ||
401 | @example | |
402 | @group | |
403 | (if @var{arg1} @var{arg1} | |
177c0ea7 | 404 | (if @var{arg2} @var{arg2} |
83ac6b45 RS |
405 | @var{arg3})) |
406 | @end group | |
407 | @end example | |
408 | ||
409 | @noindent | |
410 | This is not completely equivalent because it can evaluate @var{arg1} or | |
411 | @var{arg2} twice. By contrast, @code{(or @var{arg1} @var{arg2} | |
412 | @var{arg3})} never evaluates any argument more than once. | |
413 | @end defspec | |
414 | ||
415 | @node Iteration | |
416 | @section Iteration | |
417 | @cindex iteration | |
418 | @cindex recursion | |
419 | ||
420 | Iteration means executing part of a program repetitively. For | |
421 | example, you might want to repeat some computation once for each element | |
422 | of a list, or once for each integer from 0 to @var{n}. You can do this | |
423 | in Emacs Lisp with the special form @code{while}: | |
424 | ||
425 | @defspec while condition forms@dots{} | |
426 | @code{while} first evaluates @var{condition}. If the result is | |
427 | non-@code{nil}, it evaluates @var{forms} in textual order. Then it | |
428 | reevaluates @var{condition}, and if the result is non-@code{nil}, it | |
429 | evaluates @var{forms} again. This process repeats until @var{condition} | |
430 | evaluates to @code{nil}. | |
431 | ||
432 | There is no limit on the number of iterations that may occur. The loop | |
433 | will continue until either @var{condition} evaluates to @code{nil} or | |
434 | until an error or @code{throw} jumps out of it (@pxref{Nonlocal Exits}). | |
435 | ||
436 | The value of a @code{while} form is always @code{nil}. | |
437 | ||
438 | @example | |
439 | @group | |
440 | (setq num 0) | |
441 | @result{} 0 | |
442 | @end group | |
443 | @group | |
444 | (while (< num 4) | |
445 | (princ (format "Iteration %d." num)) | |
446 | (setq num (1+ num))) | |
447 | @print{} Iteration 0. | |
448 | @print{} Iteration 1. | |
449 | @print{} Iteration 2. | |
450 | @print{} Iteration 3. | |
451 | @result{} nil | |
452 | @end group | |
453 | @end example | |
454 | ||
8241495d RS |
455 | To write a ``repeat...until'' loop, which will execute something on each |
456 | iteration and then do the end-test, put the body followed by the | |
457 | end-test in a @code{progn} as the first argument of @code{while}, as | |
458 | shown here: | |
83ac6b45 RS |
459 | |
460 | @example | |
461 | @group | |
462 | (while (progn | |
463 | (forward-line 1) | |
464 | (not (looking-at "^$")))) | |
465 | @end group | |
466 | @end example | |
467 | ||
468 | @noindent | |
3e099569 | 469 | This moves forward one line and continues moving by lines until it |
969fe9b5 RS |
470 | reaches an empty line. It is peculiar in that the @code{while} has no |
471 | body, just the end test (which also does the real work of moving point). | |
83ac6b45 RS |
472 | @end defspec |
473 | ||
02b14400 RS |
474 | The @code{dolist} and @code{dotimes} macros provide convenient ways to |
475 | write two common kinds of loops. | |
476 | ||
477 | @defmac dolist (var list [result]) body@dots{} | |
85831f9a RS |
478 | This construct executes @var{body} once for each element of |
479 | @var{list}, binding the variable @var{var} locally to hold the current | |
480 | element. Then it returns the value of evaluating @var{result}, or | |
481 | @code{nil} if @var{result} is omitted. For example, here is how you | |
482 | could use @code{dolist} to define the @code{reverse} function: | |
02b14400 RS |
483 | |
484 | @example | |
485 | (defun reverse (list) | |
486 | (let (value) | |
487 | (dolist (elt list value) | |
488 | (setq value (cons elt value))))) | |
489 | @end example | |
490 | @end defmac | |
491 | ||
492 | @defmac dotimes (var count [result]) body@dots{} | |
02b14400 | 493 | This construct executes @var{body} once for each integer from 0 |
85831f9a RS |
494 | (inclusive) to @var{count} (exclusive), binding the variable @var{var} |
495 | to the integer for the current iteration. Then it returns the value | |
02b14400 | 496 | of evaluating @var{result}, or @code{nil} if @var{result} is omitted. |
a8d6af58 | 497 | Here is an example of using @code{dotimes} to do something 100 times: |
02b14400 RS |
498 | |
499 | @example | |
500 | (dotimes (i 100) | |
501 | (insert "I will not obey absurd orders\n")) | |
502 | @end example | |
503 | @end defmac | |
504 | ||
83ac6b45 RS |
505 | @node Nonlocal Exits |
506 | @section Nonlocal Exits | |
507 | @cindex nonlocal exits | |
508 | ||
509 | A @dfn{nonlocal exit} is a transfer of control from one point in a | |
510 | program to another remote point. Nonlocal exits can occur in Emacs Lisp | |
511 | as a result of errors; you can also use them under explicit control. | |
512 | Nonlocal exits unbind all variable bindings made by the constructs being | |
513 | exited. | |
514 | ||
515 | @menu | |
516 | * Catch and Throw:: Nonlocal exits for the program's own purposes. | |
517 | * Examples of Catch:: Showing how such nonlocal exits can be written. | |
518 | * Errors:: How errors are signaled and handled. | |
519 | * Cleanups:: Arranging to run a cleanup form if an error happens. | |
520 | @end menu | |
521 | ||
522 | @node Catch and Throw | |
523 | @subsection Explicit Nonlocal Exits: @code{catch} and @code{throw} | |
524 | ||
525 | Most control constructs affect only the flow of control within the | |
526 | construct itself. The function @code{throw} is the exception to this | |
527 | rule of normal program execution: it performs a nonlocal exit on | |
528 | request. (There are other exceptions, but they are for error handling | |
529 | only.) @code{throw} is used inside a @code{catch}, and jumps back to | |
530 | that @code{catch}. For example: | |
531 | ||
532 | @example | |
533 | @group | |
f9f59935 RS |
534 | (defun foo-outer () |
535 | (catch 'foo | |
536 | (foo-inner))) | |
537 | ||
538 | (defun foo-inner () | |
539 | @dots{} | |
540 | (if x | |
541 | (throw 'foo t)) | |
542 | @dots{}) | |
83ac6b45 RS |
543 | @end group |
544 | @end example | |
545 | ||
546 | @noindent | |
f9f59935 RS |
547 | The @code{throw} form, if executed, transfers control straight back to |
548 | the corresponding @code{catch}, which returns immediately. The code | |
549 | following the @code{throw} is not executed. The second argument of | |
550 | @code{throw} is used as the return value of the @code{catch}. | |
551 | ||
552 | The function @code{throw} finds the matching @code{catch} based on the | |
553 | first argument: it searches for a @code{catch} whose first argument is | |
554 | @code{eq} to the one specified in the @code{throw}. If there is more | |
555 | than one applicable @code{catch}, the innermost one takes precedence. | |
556 | Thus, in the above example, the @code{throw} specifies @code{foo}, and | |
557 | the @code{catch} in @code{foo-outer} specifies the same symbol, so that | |
558 | @code{catch} is the applicable one (assuming there is no other matching | |
559 | @code{catch} in between). | |
83ac6b45 RS |
560 | |
561 | Executing @code{throw} exits all Lisp constructs up to the matching | |
562 | @code{catch}, including function calls. When binding constructs such as | |
563 | @code{let} or function calls are exited in this way, the bindings are | |
564 | unbound, just as they are when these constructs exit normally | |
565 | (@pxref{Local Variables}). Likewise, @code{throw} restores the buffer | |
566 | and position saved by @code{save-excursion} (@pxref{Excursions}), and | |
567 | the narrowing status saved by @code{save-restriction} and the window | |
568 | selection saved by @code{save-window-excursion} (@pxref{Window | |
569 | Configurations}). It also runs any cleanups established with the | |
3e099569 RS |
570 | @code{unwind-protect} special form when it exits that form |
571 | (@pxref{Cleanups}). | |
83ac6b45 RS |
572 | |
573 | The @code{throw} need not appear lexically within the @code{catch} | |
574 | that it jumps to. It can equally well be called from another function | |
575 | called within the @code{catch}. As long as the @code{throw} takes place | |
576 | chronologically after entry to the @code{catch}, and chronologically | |
577 | before exit from it, it has access to that @code{catch}. This is why | |
578 | @code{throw} can be used in commands such as @code{exit-recursive-edit} | |
3e099569 | 579 | that throw back to the editor command loop (@pxref{Recursive Editing}). |
83ac6b45 RS |
580 | |
581 | @cindex CL note---only @code{throw} in Emacs | |
582 | @quotation | |
3e099569 | 583 | @b{Common Lisp note:} Most other versions of Lisp, including Common Lisp, |
83ac6b45 RS |
584 | have several ways of transferring control nonsequentially: @code{return}, |
585 | @code{return-from}, and @code{go}, for example. Emacs Lisp has only | |
586 | @code{throw}. | |
587 | @end quotation | |
588 | ||
589 | @defspec catch tag body@dots{} | |
590 | @cindex tag on run time stack | |
a9f0a989 RS |
591 | @code{catch} establishes a return point for the @code{throw} function. |
592 | The return point is distinguished from other such return points by | |
593 | @var{tag}, which may be any Lisp object except @code{nil}. The argument | |
594 | @var{tag} is evaluated normally before the return point is established. | |
83ac6b45 RS |
595 | |
596 | With the return point in effect, @code{catch} evaluates the forms of the | |
3f63de1e KH |
597 | @var{body} in textual order. If the forms execute normally (without |
598 | error or nonlocal exit) the value of the last body form is returned from | |
83ac6b45 RS |
599 | the @code{catch}. |
600 | ||
8241495d RS |
601 | If a @code{throw} is executed during the execution of @var{body}, |
602 | specifying the same value @var{tag}, the @code{catch} form exits | |
603 | immediately; the value it returns is whatever was specified as the | |
604 | second argument of @code{throw}. | |
83ac6b45 RS |
605 | @end defspec |
606 | ||
607 | @defun throw tag value | |
608 | The purpose of @code{throw} is to return from a return point previously | |
609 | established with @code{catch}. The argument @var{tag} is used to choose | |
610 | among the various existing return points; it must be @code{eq} to the value | |
611 | specified in the @code{catch}. If multiple return points match @var{tag}, | |
612 | the innermost one is used. | |
613 | ||
614 | The argument @var{value} is used as the value to return from that | |
615 | @code{catch}. | |
616 | ||
617 | @kindex no-catch | |
618 | If no return point is in effect with tag @var{tag}, then a @code{no-catch} | |
619 | error is signaled with data @code{(@var{tag} @var{value})}. | |
620 | @end defun | |
621 | ||
622 | @node Examples of Catch | |
623 | @subsection Examples of @code{catch} and @code{throw} | |
624 | ||
625 | One way to use @code{catch} and @code{throw} is to exit from a doubly | |
827b7ee7 | 626 | nested loop. (In most languages, this would be done with a ``go to.'') |
83ac6b45 RS |
627 | Here we compute @code{(foo @var{i} @var{j})} for @var{i} and @var{j} |
628 | varying from 0 to 9: | |
629 | ||
630 | @example | |
631 | @group | |
632 | (defun search-foo () | |
633 | (catch 'loop | |
634 | (let ((i 0)) | |
635 | (while (< i 10) | |
636 | (let ((j 0)) | |
637 | (while (< j 10) | |
638 | (if (foo i j) | |
639 | (throw 'loop (list i j))) | |
640 | (setq j (1+ j)))) | |
641 | (setq i (1+ i)))))) | |
642 | @end group | |
643 | @end example | |
644 | ||
645 | @noindent | |
646 | If @code{foo} ever returns non-@code{nil}, we stop immediately and return a | |
647 | list of @var{i} and @var{j}. If @code{foo} always returns @code{nil}, the | |
648 | @code{catch} returns normally, and the value is @code{nil}, since that | |
649 | is the result of the @code{while}. | |
650 | ||
651 | Here are two tricky examples, slightly different, showing two | |
652 | return points at once. First, two return points with the same tag, | |
653 | @code{hack}: | |
654 | ||
655 | @example | |
656 | @group | |
657 | (defun catch2 (tag) | |
658 | (catch tag | |
659 | (throw 'hack 'yes))) | |
660 | @result{} catch2 | |
661 | @end group | |
662 | ||
663 | @group | |
177c0ea7 | 664 | (catch 'hack |
83ac6b45 RS |
665 | (print (catch2 'hack)) |
666 | 'no) | |
667 | @print{} yes | |
668 | @result{} no | |
669 | @end group | |
670 | @end example | |
671 | ||
672 | @noindent | |
673 | Since both return points have tags that match the @code{throw}, it goes to | |
674 | the inner one, the one established in @code{catch2}. Therefore, | |
675 | @code{catch2} returns normally with value @code{yes}, and this value is | |
676 | printed. Finally the second body form in the outer @code{catch}, which is | |
677 | @code{'no}, is evaluated and returned from the outer @code{catch}. | |
678 | ||
679 | Now let's change the argument given to @code{catch2}: | |
680 | ||
681 | @example | |
83ac6b45 RS |
682 | @group |
683 | (catch 'hack | |
684 | (print (catch2 'quux)) | |
685 | 'no) | |
686 | @result{} yes | |
687 | @end group | |
688 | @end example | |
689 | ||
690 | @noindent | |
3e099569 RS |
691 | We still have two return points, but this time only the outer one has |
692 | the tag @code{hack}; the inner one has the tag @code{quux} instead. | |
693 | Therefore, @code{throw} makes the outer @code{catch} return the value | |
694 | @code{yes}. The function @code{print} is never called, and the | |
695 | body-form @code{'no} is never evaluated. | |
83ac6b45 RS |
696 | |
697 | @node Errors | |
698 | @subsection Errors | |
699 | @cindex errors | |
700 | ||
701 | When Emacs Lisp attempts to evaluate a form that, for some reason, | |
702 | cannot be evaluated, it @dfn{signals} an @dfn{error}. | |
703 | ||
704 | When an error is signaled, Emacs's default reaction is to print an | |
705 | error message and terminate execution of the current command. This is | |
706 | the right thing to do in most cases, such as if you type @kbd{C-f} at | |
707 | the end of the buffer. | |
708 | ||
709 | In complicated programs, simple termination may not be what you want. | |
710 | For example, the program may have made temporary changes in data | |
3e099569 | 711 | structures, or created temporary buffers that should be deleted before |
83ac6b45 RS |
712 | the program is finished. In such cases, you would use |
713 | @code{unwind-protect} to establish @dfn{cleanup expressions} to be | |
3e099569 RS |
714 | evaluated in case of error. (@xref{Cleanups}.) Occasionally, you may |
715 | wish the program to continue execution despite an error in a subroutine. | |
716 | In these cases, you would use @code{condition-case} to establish | |
717 | @dfn{error handlers} to recover control in case of error. | |
83ac6b45 RS |
718 | |
719 | Resist the temptation to use error handling to transfer control from | |
720 | one part of the program to another; use @code{catch} and @code{throw} | |
721 | instead. @xref{Catch and Throw}. | |
722 | ||
723 | @menu | |
724 | * Signaling Errors:: How to report an error. | |
725 | * Processing of Errors:: What Emacs does when you report an error. | |
726 | * Handling Errors:: How you can trap errors and continue execution. | |
3e099569 | 727 | * Error Symbols:: How errors are classified for trapping them. |
83ac6b45 RS |
728 | @end menu |
729 | ||
730 | @node Signaling Errors | |
731 | @subsubsection How to Signal an Error | |
732 | @cindex signaling errors | |
733 | ||
f0cdbdfa | 734 | @dfn{Signaling} an error means beginning error processing. Error |
1e0c9c18 RS |
735 | processing normally aborts all or part of the running program and |
736 | returns to a point that is set up to handle the error | |
737 | (@pxref{Processing of Errors}). Here we describe how to signal an | |
738 | error. | |
739 | ||
83ac6b45 RS |
740 | Most errors are signaled ``automatically'' within Lisp primitives |
741 | which you call for other purposes, such as if you try to take the | |
742 | @sc{car} of an integer or move forward a character at the end of the | |
3f63de1e | 743 | buffer. You can also signal errors explicitly with the functions |
83ac6b45 RS |
744 | @code{error} and @code{signal}. |
745 | ||
177c0ea7 | 746 | Quitting, which happens when the user types @kbd{C-g}, is not |
83ac6b45 RS |
747 | considered an error, but it is handled almost like an error. |
748 | @xref{Quitting}. | |
749 | ||
1e0c9c18 RS |
750 | Every error specifies an error message, one way or another. The |
751 | message should state what is wrong (``File does not exist''), not how | |
752 | things ought to be (``File must exist''). The convention in Emacs | |
753 | Lisp is that error messages should start with a capital letter, but | |
754 | should not end with any sort of punctuation. | |
8241495d | 755 | |
83ac6b45 RS |
756 | @defun error format-string &rest args |
757 | This function signals an error with an error message constructed by | |
a8d6af58 | 758 | applying @code{format} (@pxref{Formatting Strings}) to |
83ac6b45 RS |
759 | @var{format-string} and @var{args}. |
760 | ||
761 | These examples show typical uses of @code{error}: | |
762 | ||
763 | @example | |
764 | @group | |
969fe9b5 RS |
765 | (error "That is an error -- try something else") |
766 | @error{} That is an error -- try something else | |
83ac6b45 RS |
767 | @end group |
768 | ||
769 | @group | |
969fe9b5 RS |
770 | (error "You have committed %d errors" 10) |
771 | @error{} You have committed 10 errors | |
83ac6b45 RS |
772 | @end group |
773 | @end example | |
774 | ||
775 | @code{error} works by calling @code{signal} with two arguments: the | |
776 | error symbol @code{error}, and a list containing the string returned by | |
777 | @code{format}. | |
778 | ||
f9f59935 RS |
779 | @strong{Warning:} If you want to use your own string as an error message |
780 | verbatim, don't just write @code{(error @var{string})}. If @var{string} | |
781 | contains @samp{%}, it will be interpreted as a format specifier, with | |
782 | undesirable results. Instead, use @code{(error "%s" @var{string})}. | |
83ac6b45 RS |
783 | @end defun |
784 | ||
785 | @defun signal error-symbol data | |
4a76f78d | 786 | This |
7baeca0c | 787 | @anchor{Definition of signal} |
4a76f78d KB |
788 | @c unfortunately, a page break is allowed if the anchor immediately |
789 | @c follows the @defun, due to hard-to-fix TeXnicalities. | |
790 | function signals an error named by @var{error-symbol}. The | |
83ac6b45 RS |
791 | argument @var{data} is a list of additional Lisp objects relevant to the |
792 | circumstances of the error. | |
793 | ||
794 | The argument @var{error-symbol} must be an @dfn{error symbol}---a symbol | |
795 | bearing a property @code{error-conditions} whose value is a list of | |
796 | condition names. This is how Emacs Lisp classifies different sorts of | |
a8d6af58 LT |
797 | errors. @xref{Error Symbols}, for a description of error symbols, |
798 | error conditions and condition names. | |
799 | ||
800 | If the error is not handled, the two arguments are used in printing | |
801 | the error message. Normally, this error message is provided by the | |
802 | @code{error-message} property of @var{error-symbol}. If @var{data} is | |
803 | non-@code{nil}, this is followed by a colon and a comma separated list | |
804 | of the unevaluated elements of @var{data}. For @code{error}, the | |
805 | error message is the @sc{car} of @var{data} (that must be a string). | |
806 | Subcategories of @code{file-error} are handled specially. | |
83ac6b45 RS |
807 | |
808 | The number and significance of the objects in @var{data} depends on | |
809 | @var{error-symbol}. For example, with a @code{wrong-type-arg} error, | |
969fe9b5 | 810 | there should be two objects in the list: a predicate that describes the type |
3e099569 | 811 | that was expected, and the object that failed to fit that type. |
83ac6b45 RS |
812 | |
813 | Both @var{error-symbol} and @var{data} are available to any error | |
3e099569 | 814 | handlers that handle the error: @code{condition-case} binds a local |
83ac6b45 | 815 | variable to a list of the form @code{(@var{error-symbol} .@: |
a8d6af58 | 816 | @var{data})} (@pxref{Handling Errors}). |
83ac6b45 RS |
817 | |
818 | The function @code{signal} never returns (though in older Emacs versions | |
819 | it could sometimes return). | |
820 | ||
821 | @smallexample | |
822 | @group | |
823 | (signal 'wrong-number-of-arguments '(x y)) | |
824 | @error{} Wrong number of arguments: x, y | |
825 | @end group | |
826 | ||
827 | @group | |
969fe9b5 RS |
828 | (signal 'no-such-error '("My unknown error condition")) |
829 | @error{} peculiar error: "My unknown error condition" | |
83ac6b45 RS |
830 | @end group |
831 | @end smallexample | |
832 | @end defun | |
833 | ||
834 | @cindex CL note---no continuable errors | |
835 | @quotation | |
836 | @b{Common Lisp note:} Emacs Lisp has nothing like the Common Lisp | |
837 | concept of continuable errors. | |
838 | @end quotation | |
839 | ||
840 | @node Processing of Errors | |
841 | @subsubsection How Emacs Processes Errors | |
842 | ||
843 | When an error is signaled, @code{signal} searches for an active | |
844 | @dfn{handler} for the error. A handler is a sequence of Lisp | |
845 | expressions designated to be executed if an error happens in part of the | |
846 | Lisp program. If the error has an applicable handler, the handler is | |
847 | executed, and control resumes following the handler. The handler | |
3e099569 | 848 | executes in the environment of the @code{condition-case} that |
83ac6b45 RS |
849 | established it; all functions called within that @code{condition-case} |
850 | have already been exited, and the handler cannot return to them. | |
851 | ||
27ddcc19 RS |
852 | If there is no applicable handler for the error, it terminates the |
853 | current command and returns control to the editor command loop. (The | |
854 | command loop has an implicit handler for all kinds of errors.) The | |
83ac6b45 | 855 | command loop's handler uses the error symbol and associated data to |
27ddcc19 RS |
856 | print an error message. You can use the variable |
857 | @code{command-error-function} to control how this is done: | |
858 | ||
859 | @defvar command-error-function | |
860 | This variable, if non-@code{nil}, specifies a function to use to | |
861 | handle errors that return control to the Emacs command loop. The | |
862 | function should take three arguments: @var{data}, a list of the same | |
863 | form that @code{condition-case} would bind to its variable; | |
864 | @var{context}, a string describing the situation in which the error | |
b2c28d9b | 865 | occurred, or (more often) @code{nil}; and @var{caller}, the Lisp |
27ddcc19 RS |
866 | function which called the primitive that signaled the error. |
867 | @end defvar | |
83ac6b45 RS |
868 | |
869 | @cindex @code{debug-on-error} use | |
870 | An error that has no explicit handler may call the Lisp debugger. The | |
871 | debugger is enabled if the variable @code{debug-on-error} (@pxref{Error | |
872 | Debugging}) is non-@code{nil}. Unlike error handlers, the debugger runs | |
873 | in the environment of the error, so that you can examine values of | |
874 | variables precisely as they were at the time of the error. | |
875 | ||
876 | @node Handling Errors | |
877 | @subsubsection Writing Code to Handle Errors | |
878 | @cindex error handler | |
879 | @cindex handling errors | |
880 | ||
881 | The usual effect of signaling an error is to terminate the command | |
882 | that is running and return immediately to the Emacs editor command loop. | |
883 | You can arrange to trap errors occurring in a part of your program by | |
884 | establishing an error handler, with the special form | |
885 | @code{condition-case}. A simple example looks like this: | |
886 | ||
887 | @example | |
888 | @group | |
889 | (condition-case nil | |
890 | (delete-file filename) | |
891 | (error nil)) | |
892 | @end group | |
893 | @end example | |
894 | ||
895 | @noindent | |
896 | This deletes the file named @var{filename}, catching any error and | |
897 | returning @code{nil} if an error occurs. | |
898 | ||
899 | The second argument of @code{condition-case} is called the | |
900 | @dfn{protected form}. (In the example above, the protected form is a | |
901 | call to @code{delete-file}.) The error handlers go into effect when | |
902 | this form begins execution and are deactivated when this form returns. | |
903 | They remain in effect for all the intervening time. In particular, they | |
3e099569 RS |
904 | are in effect during the execution of functions called by this form, in |
905 | their subroutines, and so on. This is a good thing, since, strictly | |
83ac6b45 RS |
906 | speaking, errors can be signaled only by Lisp primitives (including |
907 | @code{signal} and @code{error}) called by the protected form, not by the | |
908 | protected form itself. | |
909 | ||
910 | The arguments after the protected form are handlers. Each handler | |
911 | lists one or more @dfn{condition names} (which are symbols) to specify | |
912 | which errors it will handle. The error symbol specified when an error | |
913 | is signaled also defines a list of condition names. A handler applies | |
914 | to an error if they have any condition names in common. In the example | |
915 | above, there is one handler, and it specifies one condition name, | |
916 | @code{error}, which covers all errors. | |
917 | ||
918 | The search for an applicable handler checks all the established handlers | |
919 | starting with the most recently established one. Thus, if two nested | |
920 | @code{condition-case} forms offer to handle the same error, the inner of | |
8241495d | 921 | the two gets to handle it. |
83ac6b45 | 922 | |
f9f59935 RS |
923 | If an error is handled by some @code{condition-case} form, this |
924 | ordinarily prevents the debugger from being run, even if | |
925 | @code{debug-on-error} says this error should invoke the debugger. | |
926 | @xref{Error Debugging}. If you want to be able to debug errors that are | |
927 | caught by a @code{condition-case}, set the variable | |
928 | @code{debug-on-signal} to a non-@code{nil} value. | |
929 | ||
83ac6b45 RS |
930 | When an error is handled, control returns to the handler. Before this |
931 | happens, Emacs unbinds all variable bindings made by binding constructs | |
932 | that are being exited and executes the cleanups of all | |
933 | @code{unwind-protect} forms that are exited. Once control arrives at | |
934 | the handler, the body of the handler is executed. | |
935 | ||
9e2b495b RS |
936 | After execution of the handler body, execution returns from the |
937 | @code{condition-case} form. Because the protected form is exited | |
938 | completely before execution of the handler, the handler cannot resume | |
939 | execution at the point of the error, nor can it examine variable | |
83ac6b45 RS |
940 | bindings that were made within the protected form. All it can do is |
941 | clean up and proceed. | |
942 | ||
969fe9b5 RS |
943 | The @code{condition-case} construct is often used to trap errors that |
944 | are predictable, such as failure to open a file in a call to | |
83ac6b45 RS |
945 | @code{insert-file-contents}. It is also used to trap errors that are |
946 | totally unpredictable, such as when the program evaluates an expression | |
947 | read from the user. | |
948 | ||
949 | Error signaling and handling have some resemblance to @code{throw} and | |
8241495d RS |
950 | @code{catch} (@pxref{Catch and Throw}), but they are entirely separate |
951 | facilities. An error cannot be caught by a @code{catch}, and a | |
952 | @code{throw} cannot be handled by an error handler (though using | |
953 | @code{throw} when there is no suitable @code{catch} signals an error | |
954 | that can be handled). | |
83ac6b45 RS |
955 | |
956 | @defspec condition-case var protected-form handlers@dots{} | |
957 | This special form establishes the error handlers @var{handlers} around | |
958 | the execution of @var{protected-form}. If @var{protected-form} executes | |
959 | without error, the value it returns becomes the value of the | |
960 | @code{condition-case} form; in this case, the @code{condition-case} has | |
961 | no effect. The @code{condition-case} form makes a difference when an | |
962 | error occurs during @var{protected-form}. | |
963 | ||
964 | Each of the @var{handlers} is a list of the form @code{(@var{conditions} | |
965 | @var{body}@dots{})}. Here @var{conditions} is an error condition name | |
966 | to be handled, or a list of condition names; @var{body} is one or more | |
967 | Lisp expressions to be executed when this handler handles an error. | |
968 | Here are examples of handlers: | |
969 | ||
970 | @smallexample | |
971 | @group | |
972 | (error nil) | |
973 | ||
974 | (arith-error (message "Division by zero")) | |
975 | ||
976 | ((arith-error file-error) | |
977 | (message | |
978 | "Either division by zero or failure to open a file")) | |
979 | @end group | |
980 | @end smallexample | |
981 | ||
3e099569 | 982 | Each error that occurs has an @dfn{error symbol} that describes what |
83ac6b45 | 983 | kind of error it is. The @code{error-conditions} property of this |
3e099569 RS |
984 | symbol is a list of condition names (@pxref{Error Symbols}). Emacs |
985 | searches all the active @code{condition-case} forms for a handler that | |
83ac6b45 RS |
986 | specifies one or more of these condition names; the innermost matching |
987 | @code{condition-case} handles the error. Within this | |
988 | @code{condition-case}, the first applicable handler handles the error. | |
989 | ||
990 | After executing the body of the handler, the @code{condition-case} | |
991 | returns normally, using the value of the last form in the handler body | |
992 | as the overall value. | |
993 | ||
840797ee | 994 | @cindex error description |
83ac6b45 RS |
995 | The argument @var{var} is a variable. @code{condition-case} does not |
996 | bind this variable when executing the @var{protected-form}, only when it | |
840797ee KH |
997 | handles an error. At that time, it binds @var{var} locally to an |
998 | @dfn{error description}, which is a list giving the particulars of the | |
999 | error. The error description has the form @code{(@var{error-symbol} | |
1000 | . @var{data})}. The handler can refer to this list to decide what to | |
1001 | do. For example, if the error is for failure opening a file, the file | |
1002 | name is the second element of @var{data}---the third element of the | |
1003 | error description. | |
83ac6b45 RS |
1004 | |
1005 | If @var{var} is @code{nil}, that means no variable is bound. Then the | |
1006 | error symbol and associated data are not available to the handler. | |
1007 | @end defspec | |
1008 | ||
840797ee KH |
1009 | @defun error-message-string error-description |
1010 | This function returns the error message string for a given error | |
1011 | descriptor. It is useful if you want to handle an error by printing the | |
a8d6af58 | 1012 | usual error message for that error. @xref{Definition of signal}. |
840797ee KH |
1013 | @end defun |
1014 | ||
83ac6b45 RS |
1015 | @cindex @code{arith-error} example |
1016 | Here is an example of using @code{condition-case} to handle the error | |
840797ee KH |
1017 | that results from dividing by zero. The handler displays the error |
1018 | message (but without a beep), then returns a very large number. | |
83ac6b45 RS |
1019 | |
1020 | @smallexample | |
1021 | @group | |
1022 | (defun safe-divide (dividend divisor) | |
177c0ea7 | 1023 | (condition-case err |
83ac6b45 | 1024 | ;; @r{Protected form.} |
177c0ea7 | 1025 | (/ dividend divisor) |
7dd3d99f RS |
1026 | @end group |
1027 | @group | |
83ac6b45 RS |
1028 | ;; @r{The handler.} |
1029 | (arith-error ; @r{Condition.} | |
840797ee KH |
1030 | ;; @r{Display the usual message for this error.} |
1031 | (message "%s" (error-message-string err)) | |
83ac6b45 RS |
1032 | 1000000))) |
1033 | @result{} safe-divide | |
1034 | @end group | |
1035 | ||
1036 | @group | |
1037 | (safe-divide 5 0) | |
1038 | @print{} Arithmetic error: (arith-error) | |
1039 | @result{} 1000000 | |
1040 | @end group | |
1041 | @end smallexample | |
1042 | ||
1043 | @noindent | |
1044 | The handler specifies condition name @code{arith-error} so that it will handle only division-by-zero errors. Other kinds of errors will not be handled, at least not by this @code{condition-case}. Thus, | |
1045 | ||
1046 | @smallexample | |
1047 | @group | |
1048 | (safe-divide nil 3) | |
f9f59935 | 1049 | @error{} Wrong type argument: number-or-marker-p, nil |
83ac6b45 RS |
1050 | @end group |
1051 | @end smallexample | |
1052 | ||
1053 | Here is a @code{condition-case} that catches all kinds of errors, | |
1054 | including those signaled with @code{error}: | |
1055 | ||
1056 | @smallexample | |
1057 | @group | |
1058 | (setq baz 34) | |
1059 | @result{} 34 | |
1060 | @end group | |
1061 | ||
1062 | @group | |
1063 | (condition-case err | |
1064 | (if (eq baz 35) | |
1065 | t | |
1066 | ;; @r{This is a call to the function @code{error}.} | |
bfe721d1 | 1067 | (error "Rats! The variable %s was %s, not 35" 'baz baz)) |
83ac6b45 | 1068 | ;; @r{This is the handler; it is not a form.} |
177c0ea7 | 1069 | (error (princ (format "The error was: %s" err)) |
83ac6b45 | 1070 | 2)) |
bfe721d1 | 1071 | @print{} The error was: (error "Rats! The variable baz was 34, not 35") |
83ac6b45 RS |
1072 | @result{} 2 |
1073 | @end group | |
1074 | @end smallexample | |
1075 | ||
3e099569 | 1076 | @node Error Symbols |
83ac6b45 RS |
1077 | @subsubsection Error Symbols and Condition Names |
1078 | @cindex error symbol | |
1079 | @cindex error name | |
1080 | @cindex condition name | |
1081 | @cindex user-defined error | |
1082 | @kindex error-conditions | |
1083 | ||
1084 | When you signal an error, you specify an @dfn{error symbol} to specify | |
1085 | the kind of error you have in mind. Each error has one and only one | |
1086 | error symbol to categorize it. This is the finest classification of | |
1087 | errors defined by the Emacs Lisp language. | |
1088 | ||
1089 | These narrow classifications are grouped into a hierarchy of wider | |
1090 | classes called @dfn{error conditions}, identified by @dfn{condition | |
1091 | names}. The narrowest such classes belong to the error symbols | |
1092 | themselves: each error symbol is also a condition name. There are also | |
1093 | condition names for more extensive classes, up to the condition name | |
a8d6af58 LT |
1094 | @code{error} which takes in all kinds of errors (but not @code{quit}). |
1095 | Thus, each error has one or more condition names: @code{error}, the | |
1096 | error symbol if that is distinct from @code{error}, and perhaps some | |
1097 | intermediate classifications. | |
83ac6b45 RS |
1098 | |
1099 | In order for a symbol to be an error symbol, it must have an | |
1100 | @code{error-conditions} property which gives a list of condition names. | |
3e099569 | 1101 | This list defines the conditions that this kind of error belongs to. |
83ac6b45 RS |
1102 | (The error symbol itself, and the symbol @code{error}, should always be |
1103 | members of this list.) Thus, the hierarchy of condition names is | |
1104 | defined by the @code{error-conditions} properties of the error symbols. | |
a8d6af58 LT |
1105 | Because quitting is not considered an error, the value of the |
1106 | @code{error-conditions} property of @code{quit} is just @code{(quit)}. | |
83ac6b45 | 1107 | |
a8d6af58 | 1108 | @cindex peculiar error |
83ac6b45 RS |
1109 | In addition to the @code{error-conditions} list, the error symbol |
1110 | should have an @code{error-message} property whose value is a string to | |
1111 | be printed when that error is signaled but not handled. If the | |
a8d6af58 | 1112 | error symbol has no @code{error-message} property or if the |
83ac6b45 | 1113 | @code{error-message} property exists, but is not a string, the error |
a8d6af58 | 1114 | message @samp{peculiar error} is used. @xref{Definition of signal}. |
83ac6b45 RS |
1115 | |
1116 | Here is how we define a new error symbol, @code{new-error}: | |
1117 | ||
1118 | @example | |
1119 | @group | |
1120 | (put 'new-error | |
1121 | 'error-conditions | |
177c0ea7 | 1122 | '(error my-own-errors new-error)) |
83ac6b45 RS |
1123 | @result{} (error my-own-errors new-error) |
1124 | @end group | |
1125 | @group | |
1126 | (put 'new-error 'error-message "A new error") | |
1127 | @result{} "A new error" | |
1128 | @end group | |
1129 | @end example | |
1130 | ||
1131 | @noindent | |
1132 | This error has three condition names: @code{new-error}, the narrowest | |
1133 | classification; @code{my-own-errors}, which we imagine is a wider | |
1134 | classification; and @code{error}, which is the widest of all. | |
bfe721d1 KH |
1135 | |
1136 | The error string should start with a capital letter but it should | |
1137 | not end with a period. This is for consistency with the rest of Emacs. | |
177c0ea7 | 1138 | |
83ac6b45 | 1139 | Naturally, Emacs will never signal @code{new-error} on its own; only |
a8d6af58 LT |
1140 | an explicit call to @code{signal} (@pxref{Definition of signal}) in |
1141 | your code can do this: | |
83ac6b45 RS |
1142 | |
1143 | @example | |
1144 | @group | |
1145 | (signal 'new-error '(x y)) | |
1146 | @error{} A new error: x, y | |
1147 | @end group | |
1148 | @end example | |
1149 | ||
1150 | This error can be handled through any of the three condition names. | |
1151 | This example handles @code{new-error} and any other errors in the class | |
1152 | @code{my-own-errors}: | |
1153 | ||
1154 | @example | |
1155 | @group | |
1156 | (condition-case foo | |
1157 | (bar nil t) | |
1158 | (my-own-errors nil)) | |
1159 | @end group | |
1160 | @end example | |
1161 | ||
1162 | The significant way that errors are classified is by their condition | |
1163 | names---the names used to match errors with handlers. An error symbol | |
1164 | serves only as a convenient way to specify the intended error message | |
1165 | and list of condition names. It would be cumbersome to give | |
1166 | @code{signal} a list of condition names rather than one error symbol. | |
1167 | ||
1168 | By contrast, using only error symbols without condition names would | |
1169 | seriously decrease the power of @code{condition-case}. Condition names | |
1170 | make it possible to categorize errors at various levels of generality | |
1171 | when you write an error handler. Using error symbols alone would | |
1172 | eliminate all but the narrowest level of classification. | |
1173 | ||
1174 | @xref{Standard Errors}, for a list of all the standard error symbols | |
1175 | and their conditions. | |
1176 | ||
1177 | @node Cleanups | |
1178 | @subsection Cleaning Up from Nonlocal Exits | |
1179 | ||
1180 | The @code{unwind-protect} construct is essential whenever you | |
1181 | temporarily put a data structure in an inconsistent state; it permits | |
85831f9a RS |
1182 | you to make the data consistent again in the event of an error or |
1183 | throw. (Another more specific cleanup construct that is used only for | |
1184 | changes in buffer contents is the atomic change group; @ref{Atomic | |
1185 | Changes}.) | |
83ac6b45 | 1186 | |
a8d6af58 | 1187 | @defspec unwind-protect body-form cleanup-forms@dots{} |
83ac6b45 RS |
1188 | @cindex cleanup forms |
1189 | @cindex protected forms | |
1190 | @cindex error cleanup | |
1191 | @cindex unwinding | |
a8d6af58 LT |
1192 | @code{unwind-protect} executes @var{body-form} with a guarantee that |
1193 | the @var{cleanup-forms} will be evaluated if control leaves | |
1194 | @var{body-form}, no matter how that happens. @var{body-form} may | |
1195 | complete normally, or execute a @code{throw} out of the | |
1196 | @code{unwind-protect}, or cause an error; in all cases, the | |
1197 | @var{cleanup-forms} will be evaluated. | |
1198 | ||
1199 | If @var{body-form} finishes normally, @code{unwind-protect} returns the | |
1200 | value of @var{body-form}, after it evaluates the @var{cleanup-forms}. | |
1201 | If @var{body-form} does not finish, @code{unwind-protect} does not | |
1202 | return any value in the normal sense. | |
1203 | ||
1204 | Only @var{body-form} is protected by the @code{unwind-protect}. If any | |
8241495d RS |
1205 | of the @var{cleanup-forms} themselves exits nonlocally (via a |
1206 | @code{throw} or an error), @code{unwind-protect} is @emph{not} | |
83ac6b45 | 1207 | guaranteed to evaluate the rest of them. If the failure of one of the |
a8d6af58 LT |
1208 | @var{cleanup-forms} has the potential to cause trouble, then protect |
1209 | it with another @code{unwind-protect} around that form. | |
83ac6b45 RS |
1210 | |
1211 | The number of currently active @code{unwind-protect} forms counts, | |
1212 | together with the number of local variable bindings, against the limit | |
a8d6af58 LT |
1213 | @code{max-specpdl-size} (@pxref{Definition of max-specpdl-size,, Local |
1214 | Variables}). | |
83ac6b45 RS |
1215 | @end defspec |
1216 | ||
1217 | For example, here we make an invisible buffer for temporary use, and | |
1218 | make sure to kill it before finishing: | |
1219 | ||
1220 | @smallexample | |
1221 | @group | |
1222 | (save-excursion | |
1223 | (let ((buffer (get-buffer-create " *temp*"))) | |
1224 | (set-buffer buffer) | |
1225 | (unwind-protect | |
a8d6af58 | 1226 | @var{body-form} |
83ac6b45 RS |
1227 | (kill-buffer buffer)))) |
1228 | @end group | |
1229 | @end smallexample | |
1230 | ||
1231 | @noindent | |
1232 | You might think that we could just as well write @code{(kill-buffer | |
1233 | (current-buffer))} and dispense with the variable @code{buffer}. | |
a8d6af58 LT |
1234 | However, the way shown above is safer, if @var{body-form} happens to |
1235 | get an error after switching to a different buffer! (Alternatively, | |
1236 | you could write another @code{save-excursion} around @var{body-form}, | |
1237 | to ensure that the temporary buffer becomes current again in time to | |
1238 | kill it.) | |
969fe9b5 RS |
1239 | |
1240 | Emacs includes a standard macro called @code{with-temp-buffer} which | |
a8d6af58 LT |
1241 | expands into more or less the code shown above (@pxref{Definition of |
1242 | with-temp-buffer,, Current Buffer}). Several of the macros defined in | |
1243 | this manual use @code{unwind-protect} in this way. | |
83ac6b45 RS |
1244 | |
1245 | @findex ftp-login | |
8241495d RS |
1246 | Here is an actual example derived from an FTP package. It creates a |
1247 | process (@pxref{Processes}) to try to establish a connection to a remote | |
1248 | machine. As the function @code{ftp-login} is highly susceptible to | |
1249 | numerous problems that the writer of the function cannot anticipate, it | |
1250 | is protected with a form that guarantees deletion of the process in the | |
1251 | event of failure. Otherwise, Emacs might fill up with useless | |
1252 | subprocesses. | |
83ac6b45 RS |
1253 | |
1254 | @smallexample | |
1255 | @group | |
1256 | (let ((win nil)) | |
1257 | (unwind-protect | |
1258 | (progn | |
1259 | (setq process (ftp-setup-buffer host file)) | |
1260 | (if (setq win (ftp-login process host user password)) | |
1261 | (message "Logged in") | |
1262 | (error "Ftp login failed"))) | |
1263 | (or win (and process (delete-process process))))) | |
1264 | @end group | |
1265 | @end smallexample | |
1266 | ||
8241495d | 1267 | This example has a small bug: if the user types @kbd{C-g} to |
83ac6b45 RS |
1268 | quit, and the quit happens immediately after the function |
1269 | @code{ftp-setup-buffer} returns but before the variable @code{process} is | |
1270 | set, the process will not be killed. There is no easy way to fix this bug, | |
1271 | but at least it is very unlikely. | |
ab5796a9 MB |
1272 | |
1273 | @ignore | |
1274 | arch-tag: 8abc30d4-4d3a-47f9-b908-e9e971c18c6d | |
1275 | @end ignore |