[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to control.texi
|
From: |
Glenn Morris |
|
Subject: |
[Emacs-diffs] Changes to control.texi |
|
Date: |
Thu, 06 Sep 2007 04:10:13 +0000 |
CVSROOT: /sources/emacs
Module name: emacs
Changes by: Glenn Morris <gm> 07/09/06 04:10:13
Index: control.texi
===================================================================
RCS file: control.texi
diff -N control.texi
--- control.texi 14 Jul 2007 18:34:17 -0000 1.34
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,1291 +0,0 @@
address@hidden -*-texinfo-*-
address@hidden This is part of the GNU Emacs Lisp Reference Manual.
address@hidden Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999,
2001, 2002,
address@hidden 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
address@hidden See the file elisp.texi for copying conditions.
address@hidden ../info/control
address@hidden Control Structures, Variables, Evaluation, Top
address@hidden Control Structures
address@hidden special forms for control structures
address@hidden control structures
-
- A Lisp program consists of expressions or @dfn{forms} (@pxref{Forms}).
-We control the order of execution of these forms by enclosing them in
address@hidden structures}. Control structures are special forms which
-control when, whether, or how many times to execute the forms they
-contain.
-
- The simplest order of execution is sequential execution: first form
address@hidden, then form @var{b}, and so on. This is what happens when you
-write several forms in succession in the body of a function, or at top
-level in a file of Lisp code---the forms are executed in the order
-written. We call this @dfn{textual order}. For example, if a function
-body consists of two forms @var{a} and @var{b}, evaluation of the
-function evaluates first @var{a} and then @var{b}. The result of
-evaluating @var{b} becomes the value of the function.
-
- Explicit control structures make possible an order of execution other
-than sequential.
-
- Emacs Lisp provides several kinds of control structure, including
-other varieties of sequencing, conditionals, iteration, and (controlled)
-jumps---all discussed below. The built-in control structures are
-special forms since their subforms are not necessarily evaluated or not
-evaluated sequentially. You can use macros to define your own control
-structure constructs (@pxref{Macros}).
-
address@hidden
-* Sequencing:: Evaluation in textual order.
-* Conditionals:: @code{if}, @code{cond}, @code{when}, @code{unless}.
-* Combining Conditions:: @code{and}, @code{or}, @code{not}.
-* Iteration:: @code{while} loops.
-* Nonlocal Exits:: Jumping out of a sequence.
address@hidden menu
-
address@hidden Sequencing
address@hidden Sequencing
-
- Evaluating forms in the order they appear is the most common way
-control passes from one form to another. In some contexts, such as in a
-function body, this happens automatically. Elsewhere you must use a
-control structure construct to do this: @code{progn}, the simplest
-control construct of Lisp.
-
- A @code{progn} special form looks like this:
-
address@hidden
address@hidden
-(progn @var{a} @var{b} @var{c} @dots{})
address@hidden group
address@hidden example
-
address@hidden
-and it says to execute the forms @var{a}, @var{b}, @var{c}, and so on, in
-that order. These forms are called the @dfn{body} of the @code{progn} form.
-The value of the last form in the body becomes the value of the entire
address@hidden @code{(progn)} returns @code{nil}.
-
address@hidden implicit @code{progn}
- In the early days of Lisp, @code{progn} was the only way to execute
-two or more forms in succession and use the value of the last of them.
-But programmers found they often needed to use a @code{progn} in the
-body of a function, where (at that time) only one form was allowed. So
-the body of a function was made into an ``implicit @code{progn}'':
-several forms are allowed just as in the body of an actual @code{progn}.
-Many other control structures likewise contain an implicit @code{progn}.
-As a result, @code{progn} is not used as much as it was many years ago.
-It is needed now most often inside an @code{unwind-protect}, @code{and},
address@hidden, or in the @var{then}-part of an @code{if}.
-
address@hidden progn address@hidden
-This special form evaluates all of the @var{forms}, in textual
-order, returning the result of the final form.
-
address@hidden
address@hidden
-(progn (print "The first form")
- (print "The second form")
- (print "The third form"))
- @print{} "The first form"
- @print{} "The second form"
- @print{} "The third form"
address@hidden "The third form"
address@hidden group
address@hidden example
address@hidden defspec
-
- Two other control constructs likewise evaluate a series of forms but return
-a different value:
-
address@hidden prog1 form1 address@hidden
-This special form evaluates @var{form1} and all of the @var{forms}, in
-textual order, returning the result of @var{form1}.
-
address@hidden
address@hidden
-(prog1 (print "The first form")
- (print "The second form")
- (print "The third form"))
- @print{} "The first form"
- @print{} "The second form"
- @print{} "The third form"
address@hidden "The first form"
address@hidden group
address@hidden example
-
-Here is a way to remove the first element from a list in the variable
address@hidden, then return the value of that former element:
-
address@hidden
-(prog1 (car x) (setq x (cdr x)))
address@hidden example
address@hidden defspec
-
address@hidden prog2 form1 form2 address@hidden
-This special form evaluates @var{form1}, @var{form2}, and all of the
-following @var{forms}, in textual order, returning the result of
address@hidden
-
address@hidden
address@hidden
-(prog2 (print "The first form")
- (print "The second form")
- (print "The third form"))
- @print{} "The first form"
- @print{} "The second form"
- @print{} "The third form"
address@hidden "The second form"
address@hidden group
address@hidden example
address@hidden defspec
-
address@hidden Conditionals
address@hidden Conditionals
address@hidden conditional evaluation
-
- Conditional control structures choose among alternatives. Emacs Lisp
-has four conditional forms: @code{if}, which is much the same as in
-other languages; @code{when} and @code{unless}, which are variants of
address@hidden; and @code{cond}, which is a generalized case statement.
-
address@hidden if condition then-form address@hidden
address@hidden chooses between the @var{then-form} and the @var{else-forms}
-based on the value of @var{condition}. If the evaluated @var{condition} is
address@hidden, @var{then-form} is evaluated and the result returned.
-Otherwise, the @var{else-forms} are evaluated in textual order, and the
-value of the last one is returned. (The @var{else} part of @code{if} is
-an example of an implicit @code{progn}. @xref{Sequencing}.)
-
-If @var{condition} has the value @code{nil}, and no @var{else-forms} are
-given, @code{if} returns @code{nil}.
-
address@hidden is a special form because the branch that is not selected is
-never evaluated---it is ignored. Thus, in the example below,
address@hidden is not printed because @code{print} is never called.
-
address@hidden
address@hidden
-(if nil
- (print 'true)
- 'very-false)
address@hidden very-false
address@hidden group
address@hidden example
address@hidden defspec
-
address@hidden when condition address@hidden
-This is a variant of @code{if} where there are no @var{else-forms},
-and possibly several @var{then-forms}. In particular,
-
address@hidden
-(when @var{condition} @var{a} @var{b} @var{c})
address@hidden example
-
address@hidden
-is entirely equivalent to
-
address@hidden
-(if @var{condition} (progn @var{a} @var{b} @var{c}) nil)
address@hidden example
address@hidden defmac
-
address@hidden unless condition address@hidden
-This is a variant of @code{if} where there is no @var{then-form}:
-
address@hidden
-(unless @var{condition} @var{a} @var{b} @var{c})
address@hidden example
-
address@hidden
-is entirely equivalent to
-
address@hidden
-(if @var{condition} nil
- @var{a} @var{b} @var{c})
address@hidden example
address@hidden defmac
-
address@hidden cond address@hidden
address@hidden chooses among an arbitrary number of alternatives. Each
address@hidden in the @code{cond} must be a list. The @sc{car} of this
-list is the @var{condition}; the remaining elements, if any, the
address@hidden Thus, a clause looks like this:
-
address@hidden
-(@var{condition} @address@hidden)
address@hidden example
-
address@hidden tries the clauses in textual order, by evaluating the
address@hidden of each clause. If the value of @var{condition} is
address@hidden, the clause ``succeeds''; then @code{cond} evaluates its
address@hidden, and the value of the last of @var{body-forms} becomes
-the value of the @code{cond}. The remaining clauses are ignored.
-
-If the value of @var{condition} is @code{nil}, the clause ``fails,'' so
-the @code{cond} moves on to the following clause, trying its
address@hidden
-
-If every @var{condition} evaluates to @code{nil}, so that every clause
-fails, @code{cond} returns @code{nil}.
-
-A clause may also look like this:
-
address@hidden
-(@var{condition})
address@hidden example
-
address@hidden
-Then, if @var{condition} is address@hidden when tested, the value of
address@hidden becomes the value of the @code{cond} form.
-
-The following example has four clauses, which test for the cases where
-the value of @code{x} is a number, string, buffer and symbol,
-respectively:
-
address@hidden
address@hidden
-(cond ((numberp x) x)
- ((stringp x) x)
- ((bufferp x)
- (setq temporary-hack x) ; @r{multiple body-forms}
- (buffer-name x)) ; @r{in one clause}
- ((symbolp x) (symbol-value x)))
address@hidden group
address@hidden example
-
-Often we want to execute the last clause whenever none of the previous
-clauses was successful. To do this, we use @code{t} as the
address@hidden of the last clause, like this: @code{(t
address@hidden)}. The form @code{t} evaluates to @code{t}, which is
-never @code{nil}, so this clause never fails, provided the @code{cond}
-gets to it at all.
-
-For example,
-
address@hidden
address@hidden
-(setq a 5)
-(cond ((eq a 'hack) 'foo)
- (t "default"))
address@hidden "default"
address@hidden group
address@hidden example
-
address@hidden
-This @code{cond} expression returns @code{foo} if the value of @code{a}
-is @code{hack}, and returns the string @code{"default"} otherwise.
address@hidden defspec
-
-Any conditional construct can be expressed with @code{cond} or with
address@hidden Therefore, the choice between them is a matter of style.
-For example:
-
address@hidden
address@hidden
-(if @var{a} @var{b} @var{c})
address@hidden
-(cond (@var{a} @var{b}) (t @var{c}))
address@hidden group
address@hidden example
-
address@hidden Combining Conditions
address@hidden Constructs for Combining Conditions
-
- This section describes three constructs that are often used together
-with @code{if} and @code{cond} to express complicated conditions. The
-constructs @code{and} and @code{or} can also be used individually as
-kinds of multiple conditional constructs.
-
address@hidden not condition
-This function tests for the falsehood of @var{condition}. It returns
address@hidden if @var{condition} is @code{nil}, and @code{nil} otherwise.
-The function @code{not} is identical to @code{null}, and we recommend
-using the name @code{null} if you are testing for an empty list.
address@hidden defun
-
address@hidden and address@hidden
-The @code{and} special form tests whether all the @var{conditions} are
-true. It works by evaluating the @var{conditions} one by one in the
-order written.
-
-If any of the @var{conditions} evaluates to @code{nil}, then the result
-of the @code{and} must be @code{nil} regardless of the remaining
address@hidden; so @code{and} returns @code{nil} right away, ignoring
-the remaining @var{conditions}.
-
-If all the @var{conditions} turn out address@hidden, then the value of
-the last of them becomes the value of the @code{and} form. Just
address@hidden(and)}, with no @var{conditions}, returns @code{t}, appropriate
-because all the @var{conditions} turned out address@hidden (Think
-about it; which one did not?)
-
-Here is an example. The first condition returns the integer 1, which is
-not @code{nil}. Similarly, the second condition returns the integer 2,
-which is not @code{nil}. The third condition is @code{nil}, so the
-remaining condition is never evaluated.
-
address@hidden
address@hidden
-(and (print 1) (print 2) nil (print 3))
- @print{} 1
- @print{} 2
address@hidden nil
address@hidden group
address@hidden example
-
-Here is a more realistic example of using @code{and}:
-
address@hidden
address@hidden
-(if (and (consp foo) (eq (car foo) 'x))
- (message "foo is a list starting with x"))
address@hidden group
address@hidden example
-
address@hidden
-Note that @code{(car foo)} is not executed if @code{(consp foo)} returns
address@hidden, thus avoiding an error.
-
address@hidden expressions can also be written using either @code{if} or
address@hidden Here's how:
-
address@hidden
address@hidden
-(and @var{arg1} @var{arg2} @var{arg3})
address@hidden
-(if @var{arg1} (if @var{arg2} @var{arg3}))
address@hidden
-(cond (@var{arg1} (cond (@var{arg2} @var{arg3}))))
address@hidden group
address@hidden example
address@hidden defspec
-
address@hidden or address@hidden
-The @code{or} special form tests whether at least one of the
address@hidden is true. It works by evaluating all the
address@hidden one by one in the order written.
-
-If any of the @var{conditions} evaluates to a address@hidden value, then
-the result of the @code{or} must be address@hidden; so @code{or} returns
-right away, ignoring the remaining @var{conditions}. The value it
-returns is the address@hidden value of the condition just evaluated.
-
-If all the @var{conditions} turn out @code{nil}, then the @code{or}
-expression returns @code{nil}. Just @code{(or)}, with no
address@hidden, returns @code{nil}, appropriate because all the
address@hidden turned out @code{nil}. (Think about it; which one
-did not?)
-
-For example, this expression tests whether @code{x} is either
address@hidden or the integer zero:
-
address@hidden
-(or (eq x nil) (eq x 0))
address@hidden example
-
-Like the @code{and} construct, @code{or} can be written in terms of
address@hidden For example:
-
address@hidden
address@hidden
-(or @var{arg1} @var{arg2} @var{arg3})
address@hidden
-(cond (@var{arg1})
- (@var{arg2})
- (@var{arg3}))
address@hidden group
address@hidden example
-
-You could almost write @code{or} in terms of @code{if}, but not quite:
-
address@hidden
address@hidden
-(if @var{arg1} @var{arg1}
- (if @var{arg2} @var{arg2}
- @var{arg3}))
address@hidden group
address@hidden example
-
address@hidden
-This is not completely equivalent because it can evaluate @var{arg1} or
address@hidden twice. By contrast, @code{(or @var{arg1} @var{arg2}
address@hidden)} never evaluates any argument more than once.
address@hidden defspec
-
address@hidden Iteration
address@hidden Iteration
address@hidden iteration
address@hidden recursion
-
- Iteration means executing part of a program repetitively. For
-example, you might want to repeat some computation once for each element
-of a list, or once for each integer from 0 to @var{n}. You can do this
-in Emacs Lisp with the special form @code{while}:
-
address@hidden while condition address@hidden
address@hidden first evaluates @var{condition}. If the result is
address@hidden, it evaluates @var{forms} in textual order. Then it
-reevaluates @var{condition}, and if the result is address@hidden, it
-evaluates @var{forms} again. This process repeats until @var{condition}
-evaluates to @code{nil}.
-
-There is no limit on the number of iterations that may occur. The loop
-will continue until either @var{condition} evaluates to @code{nil} or
-until an error or @code{throw} jumps out of it (@pxref{Nonlocal Exits}).
-
-The value of a @code{while} form is always @code{nil}.
-
address@hidden
address@hidden
-(setq num 0)
- @result{} 0
address@hidden group
address@hidden
-(while (< num 4)
- (princ (format "Iteration %d." num))
- (setq num (1+ num)))
- @print{} Iteration 0.
- @print{} Iteration 1.
- @print{} Iteration 2.
- @print{} Iteration 3.
- @result{} nil
address@hidden group
address@hidden example
-
-To write a ``repeat...until'' loop, which will execute something on each
-iteration and then do the end-test, put the body followed by the
-end-test in a @code{progn} as the first argument of @code{while}, as
-shown here:
-
address@hidden
address@hidden
-(while (progn
- (forward-line 1)
- (not (looking-at "^$"))))
address@hidden group
address@hidden example
-
address@hidden
-This moves forward one line and continues moving by lines until it
-reaches an empty line. It is peculiar in that the @code{while} has no
-body, just the end test (which also does the real work of moving point).
address@hidden defspec
-
- The @code{dolist} and @code{dotimes} macros provide convenient ways to
-write two common kinds of loops.
-
address@hidden dolist (var list [result]) address@hidden
-This construct executes @var{body} once for each element of
address@hidden, binding the variable @var{var} locally to hold the current
-element. Then it returns the value of evaluating @var{result}, or
address@hidden if @var{result} is omitted. For example, here is how you
-could use @code{dolist} to define the @code{reverse} function:
-
address@hidden
-(defun reverse (list)
- (let (value)
- (dolist (elt list value)
- (setq value (cons elt value)))))
address@hidden example
address@hidden defmac
-
address@hidden dotimes (var count [result]) address@hidden
-This construct executes @var{body} once for each integer from 0
-(inclusive) to @var{count} (exclusive), binding the variable @var{var}
-to the integer for the current iteration. Then it returns the value
-of evaluating @var{result}, or @code{nil} if @var{result} is omitted.
-Here is an example of using @code{dotimes} to do something 100 times:
-
address@hidden
-(dotimes (i 100)
- (insert "I will not obey absurd orders\n"))
address@hidden example
address@hidden defmac
-
address@hidden Nonlocal Exits
address@hidden Nonlocal Exits
address@hidden nonlocal exits
-
- A @dfn{nonlocal exit} is a transfer of control from one point in a
-program to another remote point. Nonlocal exits can occur in Emacs Lisp
-as a result of errors; you can also use them under explicit control.
-Nonlocal exits unbind all variable bindings made by the constructs being
-exited.
-
address@hidden
-* Catch and Throw:: Nonlocal exits for the program's own purposes.
-* Examples of Catch:: Showing how such nonlocal exits can be written.
-* Errors:: How errors are signaled and handled.
-* Cleanups:: Arranging to run a cleanup form if an error happens.
address@hidden menu
-
address@hidden Catch and Throw
address@hidden Explicit Nonlocal Exits: @code{catch} and @code{throw}
-
- Most control constructs affect only the flow of control within the
-construct itself. The function @code{throw} is the exception to this
-rule of normal program execution: it performs a nonlocal exit on
-request. (There are other exceptions, but they are for error handling
-only.) @code{throw} is used inside a @code{catch}, and jumps back to
-that @code{catch}. For example:
-
address@hidden
address@hidden
-(defun foo-outer ()
- (catch 'foo
- (foo-inner)))
-
-(defun foo-inner ()
- @dots{}
- (if x
- (throw 'foo t))
- @dots{})
address@hidden group
address@hidden example
-
address@hidden
-The @code{throw} form, if executed, transfers control straight back to
-the corresponding @code{catch}, which returns immediately. The code
-following the @code{throw} is not executed. The second argument of
address@hidden is used as the return value of the @code{catch}.
-
- The function @code{throw} finds the matching @code{catch} based on the
-first argument: it searches for a @code{catch} whose first argument is
address@hidden to the one specified in the @code{throw}. If there is more
-than one applicable @code{catch}, the innermost one takes precedence.
-Thus, in the above example, the @code{throw} specifies @code{foo}, and
-the @code{catch} in @code{foo-outer} specifies the same symbol, so that
address@hidden is the applicable one (assuming there is no other matching
address@hidden in between).
-
- Executing @code{throw} exits all Lisp constructs up to the matching
address@hidden, including function calls. When binding constructs such as
address@hidden or function calls are exited in this way, the bindings are
-unbound, just as they are when these constructs exit normally
-(@pxref{Local Variables}). Likewise, @code{throw} restores the buffer
-and position saved by @code{save-excursion} (@pxref{Excursions}), and
-the narrowing status saved by @code{save-restriction} and the window
-selection saved by @code{save-window-excursion} (@pxref{Window
-Configurations}). It also runs any cleanups established with the
address@hidden special form when it exits that form
-(@pxref{Cleanups}).
-
- The @code{throw} need not appear lexically within the @code{catch}
-that it jumps to. It can equally well be called from another function
-called within the @code{catch}. As long as the @code{throw} takes place
-chronologically after entry to the @code{catch}, and chronologically
-before exit from it, it has access to that @code{catch}. This is why
address@hidden can be used in commands such as @code{exit-recursive-edit}
-that throw back to the editor command loop (@pxref{Recursive Editing}).
-
address@hidden CL note---only @code{throw} in Emacs
address@hidden
address@hidden Lisp note:} Most other versions of Lisp, including Common Lisp,
-have several ways of transferring control nonsequentially: @code{return},
address@hidden, and @code{go}, for example. Emacs Lisp has only
address@hidden
address@hidden quotation
-
address@hidden catch tag address@hidden
address@hidden tag on run time stack
address@hidden establishes a return point for the @code{throw} function.
-The return point is distinguished from other such return points by
address@hidden, which may be any Lisp object except @code{nil}. The argument
address@hidden is evaluated normally before the return point is established.
-
-With the return point in effect, @code{catch} evaluates the forms of the
address@hidden in textual order. If the forms execute normally (without
-error or nonlocal exit) the value of the last body form is returned from
-the @code{catch}.
-
-If a @code{throw} is executed during the execution of @var{body},
-specifying the same value @var{tag}, the @code{catch} form exits
-immediately; the value it returns is whatever was specified as the
-second argument of @code{throw}.
address@hidden defspec
-
address@hidden throw tag value
-The purpose of @code{throw} is to return from a return point previously
-established with @code{catch}. The argument @var{tag} is used to choose
-among the various existing return points; it must be @code{eq} to the value
-specified in the @code{catch}. If multiple return points match @var{tag},
-the innermost one is used.
-
-The argument @var{value} is used as the value to return from that
address@hidden
-
address@hidden no-catch
-If no return point is in effect with tag @var{tag}, then a @code{no-catch}
-error is signaled with data @code{(@var{tag} @var{value})}.
address@hidden defun
-
address@hidden Examples of Catch
address@hidden Examples of @code{catch} and @code{throw}
-
- One way to use @code{catch} and @code{throw} is to exit from a doubly
-nested loop. (In most languages, this would be done with a ``go to.'')
-Here we compute @code{(foo @var{i} @var{j})} for @var{i} and @var{j}
-varying from 0 to 9:
-
address@hidden
address@hidden
-(defun search-foo ()
- (catch 'loop
- (let ((i 0))
- (while (< i 10)
- (let ((j 0))
- (while (< j 10)
- (if (foo i j)
- (throw 'loop (list i j)))
- (setq j (1+ j))))
- (setq i (1+ i))))))
address@hidden group
address@hidden example
-
address@hidden
-If @code{foo} ever returns address@hidden, we stop immediately and return a
-list of @var{i} and @var{j}. If @code{foo} always returns @code{nil}, the
address@hidden returns normally, and the value is @code{nil}, since that
-is the result of the @code{while}.
-
- Here are two tricky examples, slightly different, showing two
-return points at once. First, two return points with the same tag,
address@hidden:
-
address@hidden
address@hidden
-(defun catch2 (tag)
- (catch tag
- (throw 'hack 'yes)))
address@hidden catch2
address@hidden group
-
address@hidden
-(catch 'hack
- (print (catch2 'hack))
- 'no)
address@hidden yes
address@hidden no
address@hidden group
address@hidden example
-
address@hidden
-Since both return points have tags that match the @code{throw}, it goes to
-the inner one, the one established in @code{catch2}. Therefore,
address@hidden returns normally with value @code{yes}, and this value is
-printed. Finally the second body form in the outer @code{catch}, which is
address@hidden'no}, is evaluated and returned from the outer @code{catch}.
-
- Now let's change the argument given to @code{catch2}:
-
address@hidden
address@hidden
-(catch 'hack
- (print (catch2 'quux))
- 'no)
address@hidden yes
address@hidden group
address@hidden example
-
address@hidden
-We still have two return points, but this time only the outer one has
-the tag @code{hack}; the inner one has the tag @code{quux} instead.
-Therefore, @code{throw} makes the outer @code{catch} return the value
address@hidden The function @code{print} is never called, and the
-body-form @code{'no} is never evaluated.
-
address@hidden Errors
address@hidden Errors
address@hidden errors
-
- When Emacs Lisp attempts to evaluate a form that, for some reason,
-cannot be evaluated, it @dfn{signals} an @dfn{error}.
-
- When an error is signaled, Emacs's default reaction is to print an
-error message and terminate execution of the current command. This is
-the right thing to do in most cases, such as if you type @kbd{C-f} at
-the end of the buffer.
-
- In complicated programs, simple termination may not be what you want.
-For example, the program may have made temporary changes in data
-structures, or created temporary buffers that should be deleted before
-the program is finished. In such cases, you would use
address@hidden to establish @dfn{cleanup expressions} to be
-evaluated in case of error. (@xref{Cleanups}.) Occasionally, you may
-wish the program to continue execution despite an error in a subroutine.
-In these cases, you would use @code{condition-case} to establish
address@hidden handlers} to recover control in case of error.
-
- Resist the temptation to use error handling to transfer control from
-one part of the program to another; use @code{catch} and @code{throw}
-instead. @xref{Catch and Throw}.
-
address@hidden
-* Signaling Errors:: How to report an error.
-* Processing of Errors:: What Emacs does when you report an error.
-* Handling Errors:: How you can trap errors and continue execution.
-* Error Symbols:: How errors are classified for trapping them.
address@hidden menu
-
address@hidden Signaling Errors
address@hidden How to Signal an Error
address@hidden signaling errors
-
- @dfn{Signaling} an error means beginning error processing. Error
-processing normally aborts all or part of the running program and
-returns to a point that is set up to handle the error
-(@pxref{Processing of Errors}). Here we describe how to signal an
-error.
-
- Most errors are signaled ``automatically'' within Lisp primitives
-which you call for other purposes, such as if you try to take the
address@hidden of an integer or move forward a character at the end of the
-buffer. You can also signal errors explicitly with the functions
address@hidden and @code{signal}.
-
- Quitting, which happens when the user types @kbd{C-g}, is not
-considered an error, but it is handled almost like an error.
address@hidden
-
- Every error specifies an error message, one way or another. The
-message should state what is wrong (``File does not exist''), not how
-things ought to be (``File must exist''). The convention in Emacs
-Lisp is that error messages should start with a capital letter, but
-should not end with any sort of punctuation.
-
address@hidden error format-string &rest args
-This function signals an error with an error message constructed by
-applying @code{format} (@pxref{Formatting Strings}) to
address@hidden and @var{args}.
-
-These examples show typical uses of @code{error}:
-
address@hidden
address@hidden
-(error "That is an error -- try something else")
- @error{} That is an error -- try something else
address@hidden group
-
address@hidden
-(error "You have committed %d errors" 10)
- @error{} You have committed 10 errors
address@hidden group
address@hidden example
-
address@hidden works by calling @code{signal} with two arguments: the
-error symbol @code{error}, and a list containing the string returned by
address@hidden
-
address@hidden:} If you want to use your own string as an error message
-verbatim, don't just write @code{(error @var{string})}. If @var{string}
-contains @samp{%}, it will be interpreted as a format specifier, with
-undesirable results. Instead, use @code{(error "%s" @var{string})}.
address@hidden defun
-
address@hidden signal error-symbol data
address@hidden of signal}
-This function signals an error named by @var{error-symbol}. The
-argument @var{data} is a list of additional Lisp objects relevant to
-the circumstances of the error.
-
-The argument @var{error-symbol} must be an @dfn{error symbol}---a symbol
-bearing a property @code{error-conditions} whose value is a list of
-condition names. This is how Emacs Lisp classifies different sorts of
-errors. @xref{Error Symbols}, for a description of error symbols,
-error conditions and condition names.
-
-If the error is not handled, the two arguments are used in printing
-the error message. Normally, this error message is provided by the
address@hidden property of @var{error-symbol}. If @var{data} is
address@hidden, this is followed by a colon and a comma separated list
-of the unevaluated elements of @var{data}. For @code{error}, the
-error message is the @sc{car} of @var{data} (that must be a string).
-Subcategories of @code{file-error} are handled specially.
-
-The number and significance of the objects in @var{data} depends on
address@hidden For example, with a @code{wrong-type-arg} error,
-there should be two objects in the list: a predicate that describes the type
-that was expected, and the object that failed to fit that type.
-
-Both @var{error-symbol} and @var{data} are available to any error
-handlers that handle the error: @code{condition-case} binds a local
-variable to a list of the form @code{(@var{error-symbol} .@:
address@hidden)} (@pxref{Handling Errors}).
-
-The function @code{signal} never returns (though in older Emacs versions
-it could sometimes return).
-
address@hidden
address@hidden
-(signal 'wrong-number-of-arguments '(x y))
- @error{} Wrong number of arguments: x, y
address@hidden group
-
address@hidden
-(signal 'no-such-error '("My unknown error condition"))
- @error{} peculiar error: "My unknown error condition"
address@hidden group
address@hidden smallexample
address@hidden defun
-
address@hidden CL note---no continuable errors
address@hidden
address@hidden Lisp note:} Emacs Lisp has nothing like the Common Lisp
-concept of continuable errors.
address@hidden quotation
-
address@hidden Processing of Errors
address@hidden How Emacs Processes Errors
-
-When an error is signaled, @code{signal} searches for an active
address@hidden for the error. A handler is a sequence of Lisp
-expressions designated to be executed if an error happens in part of the
-Lisp program. If the error has an applicable handler, the handler is
-executed, and control resumes following the handler. The handler
-executes in the environment of the @code{condition-case} that
-established it; all functions called within that @code{condition-case}
-have already been exited, and the handler cannot return to them.
-
-If there is no applicable handler for the error, it terminates the
-current command and returns control to the editor command loop. (The
-command loop has an implicit handler for all kinds of errors.) The
-command loop's handler uses the error symbol and associated data to
-print an error message. You can use the variable
address@hidden to control how this is done:
-
address@hidden command-error-function
-This variable, if address@hidden, specifies a function to use to
-handle errors that return control to the Emacs command loop. The
-function should take three arguments: @var{data}, a list of the same
-form that @code{condition-case} would bind to its variable;
address@hidden, a string describing the situation in which the error
-occurred, or (more often) @code{nil}; and @var{caller}, the Lisp
-function which called the primitive that signaled the error.
address@hidden defvar
-
address@hidden @code{debug-on-error} use
-An error that has no explicit handler may call the Lisp debugger. The
-debugger is enabled if the variable @code{debug-on-error} (@pxref{Error
-Debugging}) is address@hidden Unlike error handlers, the debugger runs
-in the environment of the error, so that you can examine values of
-variables precisely as they were at the time of the error.
-
address@hidden Handling Errors
address@hidden Writing Code to Handle Errors
address@hidden error handler
address@hidden handling errors
-
- The usual effect of signaling an error is to terminate the command
-that is running and return immediately to the Emacs editor command loop.
-You can arrange to trap errors occurring in a part of your program by
-establishing an error handler, with the special form
address@hidden A simple example looks like this:
-
address@hidden
address@hidden
-(condition-case nil
- (delete-file filename)
- (error nil))
address@hidden group
address@hidden example
-
address@hidden
-This deletes the file named @var{filename}, catching any error and
-returning @code{nil} if an error occurs.
-
- The @code{condition-case} construct is often used to trap errors that
-are predictable, such as failure to open a file in a call to
address@hidden It is also used to trap errors that are
-totally unpredictable, such as when the program evaluates an expression
-read from the user.
-
- The second argument of @code{condition-case} is called the
address@hidden form}. (In the example above, the protected form is a
-call to @code{delete-file}.) The error handlers go into effect when
-this form begins execution and are deactivated when this form returns.
-They remain in effect for all the intervening time. In particular, they
-are in effect during the execution of functions called by this form, in
-their subroutines, and so on. This is a good thing, since, strictly
-speaking, errors can be signaled only by Lisp primitives (including
address@hidden and @code{error}) called by the protected form, not by the
-protected form itself.
-
- The arguments after the protected form are handlers. Each handler
-lists one or more @dfn{condition names} (which are symbols) to specify
-which errors it will handle. The error symbol specified when an error
-is signaled also defines a list of condition names. A handler applies
-to an error if they have any condition names in common. In the example
-above, there is one handler, and it specifies one condition name,
address@hidden, which covers all errors.
-
- The search for an applicable handler checks all the established handlers
-starting with the most recently established one. Thus, if two nested
address@hidden forms offer to handle the same error, the inner of
-the two gets to handle it.
-
- If an error is handled by some @code{condition-case} form, this
-ordinarily prevents the debugger from being run, even if
address@hidden says this error should invoke the debugger.
-
- If you want to be able to debug errors that are caught by a
address@hidden, set the variable @code{debug-on-signal} to a
address@hidden value. You can also specify that a particular handler
-should let the debugger run first, by writing @code{debug} among the
-conditions, like this:
-
address@hidden
address@hidden
-(condition-case nil
- (delete-file filename)
- ((debug error) nil))
address@hidden group
address@hidden example
-
address@hidden
-The effect of @code{debug} here is only to prevent
address@hidden from suppressing the call to the debugger. Any
-given error will invoke the debugger only if @code{debug-on-error} and
-the other usual filtering mechanisms say it should. @xref{Error Debugging}.
-
- Once Emacs decides that a certain handler handles the error, it
-returns control to that handler. To do so, Emacs unbinds all variable
-bindings made by binding constructs that are being exited, and
-executes the cleanups of all @code{unwind-protect} forms that are
-being exited. Once control arrives at the handler, the body of the
-handler executes normally.
-
- After execution of the handler body, execution returns from the
address@hidden form. Because the protected form is exited
-completely before execution of the handler, the handler cannot resume
-execution at the point of the error, nor can it examine variable
-bindings that were made within the protected form. All it can do is
-clean up and proceed.
-
- Error signaling and handling have some resemblance to @code{throw} and
address@hidden (@pxref{Catch and Throw}), but they are entirely separate
-facilities. An error cannot be caught by a @code{catch}, and a
address@hidden cannot be handled by an error handler (though using
address@hidden when there is no suitable @code{catch} signals an error
-that can be handled).
-
address@hidden condition-case var protected-form address@hidden
-This special form establishes the error handlers @var{handlers} around
-the execution of @var{protected-form}. If @var{protected-form} executes
-without error, the value it returns becomes the value of the
address@hidden form; in this case, the @code{condition-case} has
-no effect. The @code{condition-case} form makes a difference when an
-error occurs during @var{protected-form}.
-
-Each of the @var{handlers} is a list of the form @code{(@var{conditions}
address@hidden@dots{})}. Here @var{conditions} is an error condition name
-to be handled, or a list of condition names (which can include @code{debug}
-to allow the debugger to run before the handler); @var{body} is one or more
-Lisp expressions to be executed when this handler handles an error.
-Here are examples of handlers:
-
address@hidden
address@hidden
-(error nil)
-
-(arith-error (message "Division by zero"))
-
-((arith-error file-error)
- (message
- "Either division by zero or failure to open a file"))
address@hidden group
address@hidden smallexample
-
-Each error that occurs has an @dfn{error symbol} that describes what
-kind of error it is. The @code{error-conditions} property of this
-symbol is a list of condition names (@pxref{Error Symbols}). Emacs
-searches all the active @code{condition-case} forms for a handler that
-specifies one or more of these condition names; the innermost matching
address@hidden handles the error. Within this
address@hidden, the first applicable handler handles the error.
-
-After executing the body of the handler, the @code{condition-case}
-returns normally, using the value of the last form in the handler body
-as the overall value.
-
address@hidden error description
-The argument @var{var} is a variable. @code{condition-case} does not
-bind this variable when executing the @var{protected-form}, only when it
-handles an error. At that time, it binds @var{var} locally to an
address@hidden description}, which is a list giving the particulars of the
-error. The error description has the form @code{(@var{error-symbol}
-. @var{data})}. The handler can refer to this list to decide what to
-do. For example, if the error is for failure opening a file, the file
-name is the second element of @var{data}---the third element of the
-error description.
-
-If @var{var} is @code{nil}, that means no variable is bound. Then the
-error symbol and associated data are not available to the handler.
address@hidden defspec
-
address@hidden error-message-string error-description
-This function returns the error message string for a given error
-descriptor. It is useful if you want to handle an error by printing the
-usual error message for that error. @xref{Definition of signal}.
address@hidden defun
-
address@hidden @code{arith-error} example
-Here is an example of using @code{condition-case} to handle the error
-that results from dividing by zero. The handler displays the error
-message (but without a beep), then returns a very large number.
-
address@hidden
address@hidden
-(defun safe-divide (dividend divisor)
- (condition-case err
- ;; @r{Protected form.}
- (/ dividend divisor)
address@hidden group
address@hidden
- ;; @r{The handler.}
- (arith-error ; @r{Condition.}
- ;; @r{Display the usual message for this error.}
- (message "%s" (error-message-string err))
- 1000000)))
address@hidden safe-divide
address@hidden group
-
address@hidden
-(safe-divide 5 0)
- @print{} Arithmetic error: (arith-error)
address@hidden 1000000
address@hidden group
address@hidden smallexample
-
address@hidden
-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,
-
address@hidden
address@hidden
-(safe-divide nil 3)
- @error{} Wrong type argument: number-or-marker-p, nil
address@hidden group
address@hidden smallexample
-
- Here is a @code{condition-case} that catches all kinds of errors,
-including those signaled with @code{error}:
-
address@hidden
address@hidden
-(setq baz 34)
- @result{} 34
address@hidden group
-
address@hidden
-(condition-case err
- (if (eq baz 35)
- t
- ;; @r{This is a call to the function @code{error}.}
- (error "Rats! The variable %s was %s, not 35" 'baz baz))
- ;; @r{This is the handler; it is not a form.}
- (error (princ (format "The error was: %s" err))
- 2))
address@hidden The error was: (error "Rats! The variable baz was 34, not 35")
address@hidden 2
address@hidden group
address@hidden smallexample
-
address@hidden Error Symbols
address@hidden Error Symbols and Condition Names
address@hidden error symbol
address@hidden error name
address@hidden condition name
address@hidden user-defined error
address@hidden error-conditions
-
- When you signal an error, you specify an @dfn{error symbol} to specify
-the kind of error you have in mind. Each error has one and only one
-error symbol to categorize it. This is the finest classification of
-errors defined by the Emacs Lisp language.
-
- These narrow classifications are grouped into a hierarchy of wider
-classes called @dfn{error conditions}, identified by @dfn{condition
-names}. The narrowest such classes belong to the error symbols
-themselves: each error symbol is also a condition name. There are also
-condition names for more extensive classes, up to the condition name
address@hidden which takes in all kinds of errors (but not @code{quit}).
-Thus, each error has one or more condition names: @code{error}, the
-error symbol if that is distinct from @code{error}, and perhaps some
-intermediate classifications.
-
- In order for a symbol to be an error symbol, it must have an
address@hidden property which gives a list of condition names.
-This list defines the conditions that this kind of error belongs to.
-(The error symbol itself, and the symbol @code{error}, should always be
-members of this list.) Thus, the hierarchy of condition names is
-defined by the @code{error-conditions} properties of the error symbols.
-Because quitting is not considered an error, the value of the
address@hidden property of @code{quit} is just @code{(quit)}.
-
address@hidden peculiar error
- In addition to the @code{error-conditions} list, the error symbol
-should have an @code{error-message} property whose value is a string to
-be printed when that error is signaled but not handled. If the
-error symbol has no @code{error-message} property or if the
address@hidden property exists, but is not a string, the error
-message @samp{peculiar error} is used. @xref{Definition of signal}.
-
- Here is how we define a new error symbol, @code{new-error}:
-
address@hidden
address@hidden
-(put 'new-error
- 'error-conditions
- '(error my-own-errors new-error))
address@hidden (error my-own-errors new-error)
address@hidden group
address@hidden
-(put 'new-error 'error-message "A new error")
address@hidden "A new error"
address@hidden group
address@hidden example
-
address@hidden
-This error has three condition names: @code{new-error}, the narrowest
-classification; @code{my-own-errors}, which we imagine is a wider
-classification; and @code{error}, which is the widest of all.
-
- The error string should start with a capital letter but it should
-not end with a period. This is for consistency with the rest of Emacs.
-
- Naturally, Emacs will never signal @code{new-error} on its own; only
-an explicit call to @code{signal} (@pxref{Definition of signal}) in
-your code can do this:
-
address@hidden
address@hidden
-(signal 'new-error '(x y))
- @error{} A new error: x, y
address@hidden group
address@hidden example
-
- This error can be handled through any of the three condition names.
-This example handles @code{new-error} and any other errors in the class
address@hidden:
-
address@hidden
address@hidden
-(condition-case foo
- (bar nil t)
- (my-own-errors nil))
address@hidden group
address@hidden example
-
- The significant way that errors are classified is by their condition
-names---the names used to match errors with handlers. An error symbol
-serves only as a convenient way to specify the intended error message
-and list of condition names. It would be cumbersome to give
address@hidden a list of condition names rather than one error symbol.
-
- By contrast, using only error symbols without condition names would
-seriously decrease the power of @code{condition-case}. Condition names
-make it possible to categorize errors at various levels of generality
-when you write an error handler. Using error symbols alone would
-eliminate all but the narrowest level of classification.
-
- @xref{Standard Errors}, for a list of all the standard error symbols
-and their conditions.
-
address@hidden Cleanups
address@hidden Cleaning Up from Nonlocal Exits
-
- The @code{unwind-protect} construct is essential whenever you
-temporarily put a data structure in an inconsistent state; it permits
-you to make the data consistent again in the event of an error or
-throw. (Another more specific cleanup construct that is used only for
-changes in buffer contents is the atomic change group; @ref{Atomic
-Changes}.)
-
address@hidden unwind-protect body-form address@hidden
address@hidden cleanup forms
address@hidden protected forms
address@hidden error cleanup
address@hidden unwinding
address@hidden executes @var{body-form} with a guarantee that
-the @var{cleanup-forms} will be evaluated if control leaves
address@hidden, no matter how that happens. @var{body-form} may
-complete normally, or execute a @code{throw} out of the
address@hidden, or cause an error; in all cases, the
address@hidden will be evaluated.
-
-If @var{body-form} finishes normally, @code{unwind-protect} returns the
-value of @var{body-form}, after it evaluates the @var{cleanup-forms}.
-If @var{body-form} does not finish, @code{unwind-protect} does not
-return any value in the normal sense.
-
-Only @var{body-form} is protected by the @code{unwind-protect}. If any
-of the @var{cleanup-forms} themselves exits nonlocally (via a
address@hidden or an error), @code{unwind-protect} is @emph{not}
-guaranteed to evaluate the rest of them. If the failure of one of the
address@hidden has the potential to cause trouble, then protect
-it with another @code{unwind-protect} around that form.
-
-The number of currently active @code{unwind-protect} forms counts,
-together with the number of local variable bindings, against the limit
address@hidden (@pxref{Definition of max-specpdl-size,, Local
-Variables}).
address@hidden defspec
-
- For example, here we make an invisible buffer for temporary use, and
-make sure to kill it before finishing:
-
address@hidden
address@hidden
-(save-excursion
- (let ((buffer (get-buffer-create " *temp*")))
- (set-buffer buffer)
- (unwind-protect
- @var{body-form}
- (kill-buffer buffer))))
address@hidden group
address@hidden smallexample
-
address@hidden
-You might think that we could just as well write @code{(kill-buffer
-(current-buffer))} and dispense with the variable @code{buffer}.
-However, the way shown above is safer, if @var{body-form} happens to
-get an error after switching to a different buffer! (Alternatively,
-you could write another @code{save-excursion} around @var{body-form},
-to ensure that the temporary buffer becomes current again in time to
-kill it.)
-
- Emacs includes a standard macro called @code{with-temp-buffer} which
-expands into more or less the code shown above (@pxref{Definition of
-with-temp-buffer,, Current Buffer}). Several of the macros defined in
-this manual use @code{unwind-protect} in this way.
-
address@hidden ftp-login
- Here is an actual example derived from an FTP package. It creates a
-process (@pxref{Processes}) to try to establish a connection to a remote
-machine. As the function @code{ftp-login} is highly susceptible to
-numerous problems that the writer of the function cannot anticipate, it
-is protected with a form that guarantees deletion of the process in the
-event of failure. Otherwise, Emacs might fill up with useless
-subprocesses.
-
address@hidden
address@hidden
-(let ((win nil))
- (unwind-protect
- (progn
- (setq process (ftp-setup-buffer host file))
- (if (setq win (ftp-login process host user password))
- (message "Logged in")
- (error "Ftp login failed")))
- (or win (and process (delete-process process)))))
address@hidden group
address@hidden smallexample
-
- This example has a small bug: if the user types @kbd{C-g} to
-quit, and the quit happens immediately after the function
address@hidden returns but before the variable @code{process} is
-set, the process will not be killed. There is no easy way to fix this bug,
-but at least it is very unlikely.
-
address@hidden
- arch-tag: 8abc30d4-4d3a-47f9-b908-e9e971c18c6d
address@hidden ignore
- [Emacs-diffs] Changes to control.texi,
Glenn Morris <=