@node Conditions, Symbols, Structures, Top @chapter Conditions @menu * Condition System Concepts:: * Conditions Dictionary:: @end menu @node Condition System Concepts, Conditions Dictionary, Conditions, Conditions @section Condition System Concepts @c including concept-conditions Common Lisp constructs are described not only in terms of their behavior in situations during which they are intended to be used (see the ``Description'' part of each @i{operator} specification), but in all other situations (see the ``Exceptional Situations'' part of each @i{operator} specification). A situation is the evaluation of an expression in a specific context. A @i{condition} is an @i{object} that represents a specific situation that has been detected. @i{Conditions} are @i{generalized instances} of the @i{class} @b{condition}. A hierarchy of @i{condition} classes is defined in @r{Common Lisp}. A @i{condition} has @i{slots} that contain data relevant to the situation that the @i{condition} represents. An error is a situation in which normal program execution cannot continue correctly without some form of intervention (either interactively by the user or under program control). Not all errors are detected. When an error goes undetected, the effects can be @i{implementation-dependent}, @i{implementation-defined}, unspecified, or undefined. See @ref{Definitions}. All detected errors can be represented by @i{conditions}, but not all @i{conditions} represent errors. Signaling is the process by which a @i{condition} can alter the flow of control in a program by raising the @i{condition} which can then be @i{handled}. The functions @b{error}, @b{cerror}, @b{signal}, and @b{warn} are used to signal @i{conditions}. The process of signaling involves the selection and invocation of a @i{handler} from a set of @i{active} @i{handlers}. A @i{handler} is a @i{function} of one argument (the @i{condition}) that is invoked to handle a @i{condition}. Each @i{handler} is associated with a @i{condition} @i{type}, and a @i{handler} will be invoked only on a @i{condition} of the @i{handler}'s associated @i{type}. @i{Active} @i{handlers} are @i{established} dynamically (see @b{handler-bind} or @b{handler-case}). @i{Handlers} are invoked in a @i{dynamic environment} equivalent to that of the signaler, except that the set of @i{active} @i{handlers} is bound in such a way as to include only those that were @i{active} at the time the @i{handler} being invoked was @i{established}. Signaling a @i{condition} has no side-effect on the @i{condition}, and there is no dynamic state contained in a @i{condition}. If a @i{handler} is invoked, it can address the @i{situation} in one of three ways: @table @asis @item @b{Decline} It can decline to @i{handle} the @i{condition}. It does this by simply returning rather than transferring control. When this happens, any values returned by the handler are ignored and the next most recently established handler is invoked. If there is no such handler and the signaling function is @b{error} or @b{cerror}, the debugger is entered in the @i{dynamic environment} of the signaler. If there is no such handler and the signaling function is either @b{signal} or @b{warn}, the signaling function simply returns~@b{nil}. @item @b{Handle} It can @i{handle} the @i{condition} by performing a non-local transfer of control. This can be done either primitively by using @b{go}, @b{return}, @b{throw} or more abstractly by using a function such as @b{abort} or @b{invoke-restart}. @item @b{Defer} It can put off a decision about whether to @i{handle} or @i{decline}, by any of a number of actions, but most commonly by signaling another condition, resignaling the same condition, or forcing entry into the debugger. @end table @menu * Condition Types:: * Creating Conditions:: * Printing Conditions:: * Signaling and Handling Conditions:: * Assertions:: * Notes about the Condition System's Background:: @end menu @node Condition Types, Creating Conditions, Condition System Concepts, Condition System Concepts @subsection Condition Types Figure 9--1 lists the @i{standardized} @i{condition} @i{types}. Additional @i{condition} @i{types} can be defined by using @b{define-condition}. @group @noindent @w{ arithmetic-error floating-point-overflow simple-type-error } @w{ cell-error floating-point-underflow simple-warning } @w{ condition package-error storage-condition } @w{ control-error parse-error stream-error } @w{ division-by-zero print-not-readable style-warning } @w{ end-of-file program-error type-error } @w{ error reader-error unbound-slot } @w{ file-error serious-condition unbound-variable } @w{ floating-point-inexact simple-condition undefined-function } @w{ floating-point-invalid-operation simple-error warning } @noindent @w{ Figure 9--1: Standardized Condition Types } @end group All @i{condition} types are @i{subtypes} of @i{type} @b{condition}. That is, @example (typep @i{c} 'condition) @result{} @i{true} @end example if and only if @i{c} is a @i{condition}. @i{Implementations} must define all specified @i{subtype} relationships. Except where noted, all @i{subtype} relationships indicated in this document are not mutually exclusive. A @i{condition} inherits the structure of its @i{supertypes}. The metaclass of the @i{class} @b{condition} is not specified. @i{Names} of @i{condition} @i{types} may be used to specify @i{supertype} relationships in @b{define-condition}, but the consequences are not specified if an attempt is made to use a @i{condition} @i{type} as a @i{superclass} in a @b{defclass} @i{form}. Figure 9--2 shows @i{operators} that define @i{condition} @i{types} and creating @i{conditions}. @group @noindent @w{ define-condition make-condition } @noindent @w{ Figure 9--2: Operators that define and create conditions.} @end group Figure 9--3 shows @i{operators} that @i{read} the @i{value} of @i{condition} @i{slots}. @group @noindent @w{ arithmetic-error-operands simple-condition-format-arguments } @w{ arithmetic-error-operation simple-condition-format-control } @w{ cell-error-name stream-error-stream } @w{ file-error-pathname type-error-datum } @w{ package-error-package type-error-expected-type } @w{ print-not-readable-object unbound-slot-instance } @noindent @w{ Figure 9--3: Operators that read condition slots. } @end group @menu * Serious Conditions:: @end menu @node Serious Conditions, , Condition Types, Condition Types @subsubsection Serious Conditions A @i{serious condition} is a @i{condition} serious enough to require interactive intervention if not handled. @i{Serious conditions} are typically signaled with @b{error} or @b{cerror}; non-serious @i{conditions} are typically signaled with @b{signal} or @b{warn}. @node Creating Conditions, Printing Conditions, Condition Types, Condition System Concepts @subsection Creating Conditions The function @b{make-condition} can be used to construct a @i{condition} @i{object} explicitly. Functions such as @b{error}, @b{cerror}, @b{signal}, and @b{warn} operate on @i{conditions} and might create @i{condition} @i{objects} implicitly. Macros such as @b{ccase}, @b{ctypecase}, @b{ecase}, @b{etypecase}, @b{check-type}, and @b{assert} might also implicitly create (and @i{signal}) @i{conditions}. @menu * Condition Designators:: @end menu @node Condition Designators, , Creating Conditions, Creating Conditions @subsubsection Condition Designators A number of the functions in the condition system take arguments which are identified as @i{condition designators} @IGindex{condition designator} . By convention, those arguments are notated as @i{datum} {&rest} @i{arguments} Taken together, the @i{datum} and the @i{arguments} are ``@i{designators} for a @i{condition} of default type @i{default-type}.'' How the denoted @i{condition} is computed depends on the type of the @i{datum}: @table @asis @item {@t{*}} If the @i{datum} is a @i{symbol} naming a @i{condition} @i{type} ... The denoted @i{condition} is the result of @example (apply #'make-condition @i{datum} @i{arguments}) @end example @item {@t{*}} If the @i{datum} is a @i{format control} ... The denoted @i{condition} is the result of @example (make-condition @i{defaulted-type} :format-control @i{datum} :format-arguments @i{arguments}) @end example where the @i{defaulted-type} is a @i{subtype} of @i{default-type}. @item {@t{*}} If the @i{datum} is a @i{condition} ... The denoted @i{condition} is the @i{datum} itself. In this case, unless otherwise specified by the description of the @i{operator} in question, the @i{arguments} must be @i{null}; that is, the consequences are undefined if any @i{arguments} were supplied. @end table Note that the @i{default-type} gets used only in the case where the @i{datum} @i{string} is supplied. In the other situations, the resulting condition is not necessarily of @i{type} @i{default-type}. Here are some illustrations of how different @i{condition designators} can denote equivalent @i{condition} @i{objects}: @example (let ((c (make-condition 'arithmetic-error :operator '/ :operands '(7 0)))) (error c)) @equiv{} (error 'arithmetic-error :operator '/ :operands '(7 0)) (error "Bad luck.") @equiv{} (error 'simple-error :format-control "Bad luck." :format-arguments '()) @end example @node Printing Conditions, Signaling and Handling Conditions, Creating Conditions, Condition System Concepts @subsection Printing Conditions If the @t{:report} argument to @b{define-condition} is used, a print function is defined that is called whenever the defined @i{condition} is printed while the @i{value} of @b{*print-escape*} is @i{false}. This function is called the @i{condition reporter} @IGindex{condition reporter} ; the text which it outputs is called a @i{report message} @IGindex{report message} . When a @i{condition} is printed and @b{*print-escape*} is @i{false}, the @i{condition reporter} for the @i{condition} is invoked. @i{Conditions} are printed automatically by functions such as @b{invoke-debugger}, @b{break}, and @b{warn}. When @b{*print-escape*} is @i{true}, the @i{object} should print in an abbreviated fashion according to the style of the implementation (@i{e.g.}, by @b{print-unreadable-object}). It is not required that a @i{condition} can be recreated by reading its printed representation. No @i{function} is provided for directly @i{accessing} or invoking @i{condition reporters}. @menu * Recommended Style in Condition Reporting:: * Capitalization and Punctuation in Condition Reports:: * Leading and Trailing Newlines in Condition Reports:: * Embedded Newlines in Condition Reports:: * Note about Tabs in Condition Reports:: * Mentioning Containing Function in Condition Reports:: @end menu @node Recommended Style in Condition Reporting, Capitalization and Punctuation in Condition Reports, Printing Conditions, Printing Conditions @subsubsection Recommended Style in Condition Reporting In order to ensure a properly aesthetic result when presenting @i{report messages} to the user, certain stylistic conventions are recommended. There are stylistic recommendations for the content of the messages output by @i{condition reporters}, but there are no formal requirements on those @i{programs}. If a @i{program} violates the recommendations for some message, the display of that message might be less aesthetic than if the guideline had been observed, but the @i{program} is still considered a @i{conforming program}. The requirements on a @i{program} or @i{implementation} which invokes a @i{condition reporter} are somewhat stronger. A @i{conforming program} must be permitted to assume that if these style guidelines are followed, proper aesthetics will be maintained. Where appropriate, any specific requirements on such routines are explicitly mentioned below. @node Capitalization and Punctuation in Condition Reports, Leading and Trailing Newlines in Condition Reports, Recommended Style in Condition Reporting, Printing Conditions @subsubsection Capitalization and Punctuation in Condition Reports It is recommended that a @i{report message} be a complete sentences, in the proper case and correctly punctuated. In English, for example, this means the first letter should be uppercase, and there should be a trailing period. @example (error "This is a message") ; Not recommended (error "this is a message.") ; Not recommended (error "This is a message.") ; Recommended instead @end example @node Leading and Trailing Newlines in Condition Reports, Embedded Newlines in Condition Reports, Capitalization and Punctuation in Condition Reports, Printing Conditions @subsubsection Leading and Trailing Newlines in Condition Reports It is recommended that a @i{report message} not begin with any introductory text, such as ``@t{Error: }'' or ``@t{Warning: }'' or even just @i{freshline} or @i{newline}. Such text is added, if appropriate to the context, by the routine invoking the @i{condition reporter}. It is recommended that a @i{report message} not be followed by a trailing @i{freshline} or @i{newline}. Such text is added, if appropriate to the context, by the routine invoking the @i{condition reporter}. @example (error "This is a message.~ (error "~&This is a message.") ; Not recommended (error "~&This is a message.~ (error "This is a message.") ; Recommended instead @end example @node Embedded Newlines in Condition Reports, Note about Tabs in Condition Reports, Leading and Trailing Newlines in Condition Reports, Printing Conditions @subsubsection Embedded Newlines in Condition Reports Especially if it is long, it is permissible and appropriate for a @i{report message} to contain one or more embedded @i{newlines}. If the calling routine conventionally inserts some additional prefix (such as ``@t{Error: }'' or ``@t{;; Error: }'') on the first line of the message, it must also assure that an appropriate prefix will be added to each subsequent line of the output, so that the left edge of the message output by the @i{condition reporter} will still be properly aligned. @example (defun test () (error "This is an error message.~%It has two lines.")) ;; Implementation A (test) This is an error message. It has two lines. ;; Implementation B (test) ;; Error: This is an error message. ;; It has two lines. ;; Implementation C (test) >> Error: This is an error message. It has two lines. @end example @node Note about Tabs in Condition Reports, Mentioning Containing Function in Condition Reports, Embedded Newlines in Condition Reports, Printing Conditions @subsubsection Note about Tabs in Condition Reports Because the indentation of a @i{report message} might be shifted to the right or left by an arbitrary amount, special care should be taken with the semi-standard @i{character} <@i{Tab}> (in those @i{implementations} that support such a @i{character}). Unless the @i{implementation} specifically defines its behavior in this context, its use should be avoided. @node Mentioning Containing Function in Condition Reports, , Note about Tabs in Condition Reports, Printing Conditions @subsubsection Mentioning Containing Function in Condition Reports The name of the containing function should generally not be mentioned in @i{report messages}. It is assumed that the @i{debugger} will make this information accessible in situations where it is necessary and appropriate. @node Signaling and Handling Conditions, Assertions, Printing Conditions, Condition System Concepts @subsection Signaling and Handling Conditions The operation of the condition system depends on the ordering of active @i{applicable handlers} from most recent to least recent. Each @i{handler} is associated with a @i{type specifier} that must designate a @i{subtype} of @i{type} @b{condition}. A @i{handler} is said to be @i{applicable} to a @i{condition} if that @i{condition} is of the @i{type} designated by the associated @i{type specifier}. @i{Active} @i{handlers} are @i{established} by using @b{handler-bind} (or an abstraction based on @b{handler-bind}, such as @b{handler-case} or @b{ignore-errors}). @i{Active} @i{handlers} can be @i{established} within the dynamic scope of other @i{active} @i{handlers}. At any point during program execution, there is a set of @i{active} @i{handlers}. When a @i{condition} is signaled, the @i{most recent} active @i{applicable handler} for that @i{condition} is selected from this set. Given a @i{condition}, the order of recentness of active @i{applicable handlers} is defined by the following two rules: @table @asis @item 1. Each handler in a set of active handlers H_1 is more recent than every handler in a set H_2 if the handlers in H_2 were active when the handlers in H_1 were established. @item 2. Let h_1 and h_2 be two applicable active handlers established by the same @i{form}. Then h_1 is more recent than h_2 if h_1 was defined to the left of h_2 in the @i{form} that established them. @end table Once a handler in a handler binding @i{form} (such as @b{handler-bind} or @b{handler-case}) has been selected, all handlers in that @i{form} become inactive for the remainder of the signaling process. While the selected @i{handler} runs, no other @i{handler} established by that @i{form} is active. That is, if the @i{handler} declines, no other handler established by that @i{form} will be considered for possible invocation. Figure 9--4 shows @i{operators} relating to the @i{handling} of @i{conditions}. @group @noindent @w{ handler-bind handler-case ignore-errors } @noindent @w{ Figure 9--4: Operators relating to handling conditions.} @end group @menu * Signaling:: * Resignaling a Condition:: * Restarts:: * Interactive Use of Restarts:: * Interfaces to Restarts:: * Restart Tests:: * Associating a Restart with a Condition:: @end menu @node Signaling, Resignaling a Condition, Signaling and Handling Conditions, Signaling and Handling Conditions @subsubsection Signaling When a @i{condition} is signaled, the most recent applicable @i{active} @i{handler} is invoked. Sometimes a handler will decline by simply returning without a transfer of control. In such cases, the next most recent applicable active handler is invoked. If there are no applicable handlers for a @i{condition} that has been signaled, or if all applicable handlers decline, the @i{condition} is unhandled. The functions @b{cerror} and @b{error} invoke the interactive @i{condition} handler (the debugger) rather than return if the @i{condition} being signaled, regardless of its @i{type}, is unhandled. In contrast, @b{signal} returns @b{nil} if the @i{condition} being signaled, regardless of its @i{type}, is unhandled. The @i{variable} @b{*break-on-signals*} can be used to cause the debugger to be entered before the signaling process begins. Figure 9--5 shows @i{defined names} relating to the @i{signaling} of @i{conditions}. @group @noindent @w{ *break-on-signals* error warn } @w{ cerror signal } @noindent @w{ Figure 9--5: Defined names relating to signaling conditions.} @end group @node Resignaling a Condition, Restarts, Signaling, Signaling and Handling Conditions @subsubsection Resignaling a Condition During the @i{dynamic extent} of the @i{signaling} process for a particular @i{condition} @i{object}, @b{signaling} the same @i{condition} @i{object} again is permitted if and only if the @i{situation} represented in both cases are the same. For example, a @i{handler} might legitimately @i{signal} the @i{condition} @i{object} that is its @i{argument} in order to allow outer @i{handlers} first opportunity to @i{handle} the condition. (Such a @i{handlers} is sometimes called a ``default handler.'') This action is permitted because the @i{situation} which the second @i{signaling} process is addressing is really the same @i{situation}. On the other hand, in an @i{implementation} that implemented asynchronous keyboard events by interrupting the user process with a call to @b{signal}, it would not be permissible for two distinct asynchronous keyboard events to @i{signal} @i{identical} @i{condition} @i{objects} at the same time for different situations. @node Restarts, Interactive Use of Restarts, Resignaling a Condition, Signaling and Handling Conditions @subsubsection Restarts The interactive condition handler returns only through non-local transfer of control to specially defined @i{restarts} that can be set up either by the system or by user code. Transferring control to a restart is called ``invoking'' the restart. Like handlers, active @i{restarts} are @i{established} dynamically, and only active @i{restarts} can be invoked. An active @i{restart} can be invoked by the user from the debugger or by a program by using @b{invoke-restart}. A @i{restart} contains a @i{function} to be @i{called} when the @i{restart} is invoked, an optional name that can be used to find or invoke the @i{restart}, and an optional set of interaction information for the debugger to use to enable the user to manually invoke a @i{restart}. The name of a @i{restart} is used by @b{invoke-restart}. @i{Restarts} that can be invoked only within the debugger do not need names. @i{Restarts} can be established by using @b{restart-bind}, @b{restart-case}, and @b{with-simple-restart}. A @i{restart} function can itself invoke any other @i{restart} that was active at the time of establishment of the @i{restart} of which the @i{function} is part. The @i{restarts} @i{established} by a @b{restart-bind} @i{form}, a @b{restart-case} @i{form}, or a @b{with-simple-restart} @i{form} have @i{dynamic extent} which extends for the duration of that @i{form}'s execution. @i{Restarts} of the same name can be ordered from least recent to most recent according to the following two rules: @table @asis @item 1. Each @i{restart} in a set of active restarts R_1 is more recent than every @i{restart} in a set R_2 if the @i{restarts} in R_2 were active when the @i{restarts} in R_1 were established. @item 2. Let r_1 and r_2 be two active @i{restarts} with the same name established by the same @i{form}. Then r_1 is more recent than r_2 if r_1 was defined to the left of r_2 in the @i{form} that established them. @end table If a @i{restart} is invoked but does not transfer control, the values resulting from the @i{restart} function are returned by the function that invoked the restart, either @b{invoke-restart} or @b{invoke-restart-interactively}. @node Interactive Use of Restarts, Interfaces to Restarts, Restarts, Signaling and Handling Conditions @subsubsection Interactive Use of Restarts For interactive handling, two pieces of information are needed from a @i{restart}: a report function and an interactive function. The report function is used by a program such as the debugger to present a description of the action the @i{restart} will take. The report function is specified and established by the @t{:report-function} keyword to @b{restart-bind} or the @t{:report} keyword to @b{restart-case}. The interactive function, which can be specified using the @t{:interactive-function} keyword to @b{restart-bind} or @t{:interactive} keyword to @b{restart-case}, is used when the @i{restart} is invoked interactively, such as from the debugger, to produce a suitable list of arguments. @b{invoke-restart} invokes the most recently @i{established} @i{restart} whose name is the same as the first argument to @b{invoke-restart}. If a @i{restart} is invoked interactively by the debugger and does not transfer control but rather returns values, the precise action of the debugger on those values is @i{implementation-defined}. @node Interfaces to Restarts, Restart Tests, Interactive Use of Restarts, Signaling and Handling Conditions @subsubsection Interfaces to Restarts Some @i{restarts} have functional interfaces, such as @b{abort}, @b{continue}, @b{muffle-warning}, @b{store-value}, and @b{use-value}. They are ordinary functions that use @b{find-restart} and @b{invoke-restart} internally, that have the same name as the @i{restarts} they manipulate, and that are provided simply for notational convenience. Figure 9--6 shows @i{defined names} relating to @i{restarts}. @group @noindent @w{ abort invoke-restart-interactively store-value } @w{ compute-restarts muffle-warning use-value } @w{ continue restart-bind with-simple-restart } @w{ find-restart restart-case } @w{ invoke-restart restart-name } @noindent @w{ Figure 9--6: Defined names relating to restarts. } @end group @node Restart Tests, Associating a Restart with a Condition, Interfaces to Restarts, Signaling and Handling Conditions @subsubsection Restart Tests Each @i{restart} has an associated test, which is a function of one argument (a @i{condition} or @b{nil}) which returns @i{true} if the @i{restart} should be visible in the current @i{situation}. This test is created by the @t{:test-function} option to @b{restart-bind} or the @t{:test} option to @b{restart-case}. @node Associating a Restart with a Condition, , Restart Tests, Signaling and Handling Conditions @subsubsection Associating a Restart with a Condition A @i{restart} can be ``associated with'' a @i{condition} explicitly by @b{with-condition-restarts}, or implicitly by @b{restart-case}. Such an assocation has @i{dynamic extent}. A single @i{restart} may be associated with several @i{conditions} at the same time. A single @i{condition} may have several associated @i{restarts} at the same time. Active restarts associated with a particular @i{condition} can be detected by @i{calling} a @i{function} such as @b{find-restart}, supplying that @i{condition} as the @i{condition} @i{argument}. Active restarts can also be detected without regard to any associated @i{condition} by calling such a function without a @i{condition} @i{argument}, or by supplying a value of @b{nil} for such an @i{argument}. @node Assertions, Notes about the Condition System's Background, Signaling and Handling Conditions, Condition System Concepts @subsection Assertions Conditional signaling of @i{conditions} based on such things as key match, form evaluation, and @i{type} are handled by assertion @i{operators}. Figure 9--7 shows @i{operators} relating to assertions. @group @noindent @w{ assert check-type ecase } @w{ ccase ctypecase etypecase } @noindent @w{ Figure 9--7: Operators relating to assertions.} @end group @node Notes about the Condition System's Background, , Assertions, Condition System Concepts @subsection Notes about the Condition System's Background For a background reference to the abstract concepts detailed in this section, see @i{Exceptional Situations in Lisp}. The details of that paper are not binding on this document, but may be helpful in establishing a conceptual basis for understanding this material. @c end of including concept-conditions @node Conditions Dictionary, , Condition System Concepts, Conditions @section Conditions Dictionary @c including dict-conditions @menu * condition:: * warning:: * style-warning:: * serious-condition:: * error (Condition Type):: * cell-error:: * cell-error-name:: * parse-error:: * storage-condition:: * assert:: * error:: * cerror:: * check-type:: * simple-error:: * invalid-method-error:: * method-combination-error:: * signal:: * simple-condition:: * simple-condition-format-control:: * warn:: * simple-warning:: * invoke-debugger:: * break:: * *debugger-hook*:: * *break-on-signals*:: * handler-bind:: * handler-case:: * ignore-errors:: * define-condition:: * make-condition:: * restart:: * compute-restarts:: * find-restart:: * invoke-restart:: * invoke-restart-interactively:: * restart-bind:: * restart-case:: * restart-name:: * with-condition-restarts:: * with-simple-restart:: * abort:: * continue:: * muffle-warning:: * store-value:: * use-value:: * abort:: @end menu @node condition, warning, Conditions Dictionary, Conditions Dictionary @subsection condition [Condition Type] [Reviewer Note by Barrett: I think CONDITION-RESTARTS is not fully integrated.] @subsubheading Class Precedence List:: @b{condition}, @b{t} @subsubheading Description:: All types of @i{conditions}, whether error or non-error, must inherit from this @i{type}. No additional @i{subtype} relationships among the specified @i{subtypes} of @i{type} @b{condition} are allowed, except when explicitly mentioned in the text; however implementations are permitted to introduce additional @i{types} and one of these @i{types} can be a @i{subtype} of any number of the @i{subtypes} of @i{type} @b{condition}. Whether a user-defined @i{condition} @i{type} has @i{slots} that are accessible by @i{with-slots} is @i{implementation-dependent}. Furthermore, even in an @i{implementation} in which user-defined @i{condition} @i{types} would have @i{slots}, it is @i{implementation-dependent} whether any @i{condition} @i{types} defined in this document have such @i{slots} or, if they do, what their @i{names} might be; only the reader functions documented by this specification may be relied upon by portable code. @i{Conforming code} must observe the following restrictions related to @i{conditions}: @table @asis @item @t{*} @b{define-condition}, not @b{defclass}, must be used to define new @i{condition} @i{types}. @item @t{*} @b{make-condition}, not @b{make-instance}, must be used to create @i{condition} @i{objects} explicitly. @item @t{*} The @t{:report} option of @b{define-condition}, not @b{defmethod} for @b{print-object}, must be used to define a condition reporter. @item @t{*} @b{slot-value}, @b{slot-boundp}, @b{slot-makunbound}, and @b{with-slots} must not be used on @i{condition} @i{objects}. Instead, the appropriate accessor functions (defined by @b{define-condition}) should be used. @end table @node warning, style-warning, condition, Conditions Dictionary @subsection warning [Condition Type] @subsubheading Class Precedence List:: @b{warning}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{warning} consists of all types of warnings. @subsubheading See Also:: @b{style-warning} @node style-warning, serious-condition, warning, Conditions Dictionary @subsection style-warning [Condition Type] @subsubheading Class Precedence List:: @b{style-warning}, @b{warning}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{style-warning} includes those @i{conditions} that represent @i{situations} involving @i{code} that is @i{conforming code} but that is nevertheless considered to be faulty or substandard. @subsubheading See Also:: @ref{muffle-warning} @subsubheading Notes:: An @i{implementation} might signal such a @i{condition} if it encounters @i{code} that uses deprecated features or that appears unaesthetic or inefficient. An `unused variable' warning must be of @i{type} @b{style-warning}. In general, the question of whether @i{code} is faulty or substandard is a subjective decision to be made by the facility processing that @i{code}. The intent is that whenever such a facility wishes to complain about @i{code} on such subjective grounds, it should use this @i{condition} @i{type} so that any clients who wish to redirect or muffle superfluous warnings can do so without risking that they will be redirecting or muffling other, more serious warnings. @node serious-condition, error (Condition Type), style-warning, Conditions Dictionary @subsection serious-condition [Condition Type] @subsubheading Class Precedence List:: @b{serious-condition}, @b{condition}, @b{t} @subsubheading Description:: All @i{conditions} serious enough to require interactive intervention if not handled should inherit from the @i{type} @b{serious-condition}. This condition type is provided primarily so that it may be included as a @i{superclass} of other @i{condition} @i{types}; it is not intended to be signaled directly. @subsubheading Notes:: Signaling a @i{serious condition} does not itself force entry into the debugger. However, except in the unusual situation where the programmer can assure that no harm will come from failing to @i{handle} a @i{serious condition}, such a @i{condition} is usually signaled with @b{error} rather than @b{signal} in order to assure that the program does not continue without @i{handling} the @i{condition}. (And conversely, it is conventional to use @b{signal} rather than @b{error} to signal conditions which are not @i{serious conditions}, since normally the failure to handle a non-serious condition is not reason enough for the debugger to be entered.) @node error (Condition Type), cell-error, serious-condition, Conditions Dictionary @subsection error [Condition Type] @subsubheading Class Precedence List:: @b{error}, @b{serious-condition}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{error} consists of all @i{conditions} that represent @i{errors}. @node cell-error, cell-error-name, error (Condition Type), Conditions Dictionary @subsection cell-error [Condition Type] @subsubheading Class Precedence List:: @b{cell-error}, @b{error}, @b{serious-condition}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{cell-error} consists of error conditions that occur during a location @i{access}. The name of the offending cell is initialized by the @t{:name} initialization argument to @b{make-condition}, and is @i{accessed} by the @i{function} @b{cell-error-name}. @subsubheading See Also:: @ref{cell-error-name} @node cell-error-name, parse-error, cell-error, Conditions Dictionary @subsection cell-error-name [Function] @code{cell-error-name} @i{condition} @result{} @i{name} @subsubheading Arguments and Values:: @i{condition}---a @i{condition} of @i{type} @b{cell-error}. @i{name}---an @i{object}. @subsubheading Description:: Returns the @i{name} of the offending cell involved in the @i{situation} represented by @i{condition}. The nature of the result depends on the specific @i{type} of @i{condition}. For example, if the @i{condition} is of @i{type} @b{unbound-variable}, the result is the @i{name} of the @i{unbound variable} which was being @i{accessed}, if the @i{condition} is of @i{type} @b{undefined-function}, this is the @i{name} of the @i{undefined function} which was being @i{accessed}, and if the @i{condition} is of @i{type} @b{unbound-slot}, this is the @i{name} of the @i{slot} which was being @i{accessed}. @subsubheading See Also:: @b{cell-error}, @b{unbound-slot}, @b{unbound-variable}, @b{undefined-function}, @ref{Condition System Concepts} @node parse-error, storage-condition, cell-error-name, Conditions Dictionary @subsection parse-error [Condition Type] @subsubheading Class Precedence List:: @b{parse-error}, @b{error}, @b{serious-condition}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{parse-error} consists of error conditions that are related to parsing. @subsubheading See Also:: @ref{parse-namestring} , @ref{reader-error} @node storage-condition, assert, parse-error, Conditions Dictionary @subsection storage-condition [Condition Type] @subsubheading Class Precedence List:: @b{storage-condition}, @b{serious-condition}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{storage-condition} consists of serious conditions that relate to problems with memory management that are potentially due to @i{implementation-dependent} limits rather than semantic errors in @i{conforming programs}, and that typically warrant entry to the debugger if not handled. Depending on the details of the @i{implementation}, these might include such problems as stack overflow, memory region overflow, and storage exhausted. @subsubheading Notes:: While some @r{Common Lisp} operations might signal @i{storage-condition} because they are defined to create @i{objects}, it is unspecified whether operations that are not defined to create @i{objects} create them anyway and so might also signal @b{storage-condition}. Likewise, the evaluator itself might create @i{objects} and so might signal @b{storage-condition}. (The natural assumption might be that such @i{object} creation is naturally inefficient, but even that is @i{implementation-dependent}.) In general, the entire question of how storage allocation is done is @i{implementation-dependent}, and so any operation might signal @b{storage-condition} at any time. Because such a @i{condition} is indicative of a limitation of the @i{implementation} or of the @i{image} rather than an error in a @i{program}, @i{objects} of @i{type} @b{storage-condition} are not of @i{type} @b{error}. @node assert, error, storage-condition, Conditions Dictionary @subsection assert [Macro] @code{assert} @i{test-form @r{[}@r{(}@{@i{place}@}{*}@r{)} @r{[}datum-form @{@i{argument-form}@}{*}@r{]}@r{]}}@* @result{} @i{@b{nil}} @subsubheading Arguments and Values:: @i{test-form}---a @i{form}; always evaluated. @i{place}---a @i{place}; evaluated if an error is signaled. @i{datum-form}---a @i{form} that evaluates to a @i{datum}. Evaluated each time an error is to be signaled, or not at all if no error is to be signaled. @i{argument-form}---a @i{form} that evaluates to an @i{argument}. Evaluated each time an error is to be signaled, or not at all if no error is to be signaled. @i{datum}, @i{arguments}---@i{designators} for a @i{condition} of default type @b{error}. (These @i{designators} are the result of evaluating @i{datum-form} and each of the @i{argument-forms}.) @subsubheading Description:: @b{assert} assures that @i{test-form} evaluates to @i{true}. If @i{test-form} evaluates to @i{false}, @b{assert} signals a @i{correctable} @i{error} (denoted by @i{datum} and @i{arguments}). Continuing from this error using the @b{continue} @i{restart} makes it possible for the user to alter the values of the @i{places} before @b{assert} evaluates @i{test-form} again. If the value of @i{test-form} is @i{non-nil}, @b{assert} returns @b{nil}. The @i{places} are @i{generalized references} to data upon which @i{test-form} depends, whose values can be changed by the user in attempting to correct the error. @i{Subforms} of each @i{place} are only evaluated if an error is signaled, and might be re-evaluated if the error is re-signaled (after continuing without actually fixing the problem). The order of evaluation of the @i{places} is not specified; see @ref{Evaluation of Subforms to Places}. @ITindex{order of evaluation} @ITindex{evaluation order} If a @i{place} @i{form} is supplied that produces more values than there are store variables, the extra values are ignored. If the supplied @i{form} produces fewer values than there are store variables, the missing values are set to @b{nil}. @subsubheading Examples:: @example (setq x (make-array '(3 5) :initial-element 3)) @result{} #2A((3 3 3 3 3) (3 3 3 3 3) (3 3 3 3 3)) (setq y (make-array '(3 5) :initial-element 7)) @result{} #2A((7 7 7 7 7) (7 7 7 7 7) (7 7 7 7 7)) (defun matrix-multiply (a b) (let ((*print-array* nil)) (assert (and (= (array-rank a) (array-rank b) 2) (= (array-dimension a 1) (array-dimension b 0))) (a b) "Cannot multiply ~S by ~S." a b) (really-matrix-multiply a b))) @result{} MATRIX-MULTIPLY (matrix-multiply x y) @t{ |> } Correctable error in MATRIX-MULTIPLY: @t{ |> } Cannot multiply # by #. @t{ |> } Restart options: @t{ |> } 1: You will be prompted for one or more new values. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @t{ |> } Value for A: @b{|>>}@t{x}@b{<<|} @t{ |> } Value for B: @b{|>>}@t{(make-array '(5 3) :initial-element 6)}@b{<<|} @result{} #2A((54 54 54 54 54) (54 54 54 54 54) (54 54 54 54 54) (54 54 54 54 54) (54 54 54 54 54)) @end example @example (defun double-safely (x) (assert (numberp x) (x)) (+ x x)) (double-safely 4) @result{} 8 (double-safely t) @t{ |> } Correctable error in DOUBLE-SAFELY: The value of (NUMBERP X) must be non-NIL. @t{ |> } Restart options: @t{ |> } 1: You will be prompted for one or more new values. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @t{ |> } Value for X: @b{|>>}@t{7}@b{<<|} @result{} 14 @end example @subsubheading Affected By:: @b{*break-on-signals*} The set of active @i{condition handlers}. @subsubheading See Also:: @ref{check-type} , @ref{error} , @ref{Generalized Reference} @subsubheading Notes:: The debugger need not include the @i{test-form} in the error message, and the @i{places} should not be included in the message, but they should be made available for the user's perusal. If the user gives the ``continue'' command, the values of any of the references can be altered. The details of this depend on the implementation's style of user interface. @node error, cerror, assert, Conditions Dictionary @subsection error [Function] @code{error} @i{datum {&rest} arguments} @result{} # @subsubheading Arguments and Values:: @i{datum}, @i{arguments}---@i{designators} for a @i{condition} of default type @b{simple-error}. @subsubheading Description:: @b{error} effectively invokes @b{signal} on the denoted @i{condition}. If the @i{condition} is not handled, @t{(invoke-debugger @i{condition})} is done. As a consequence of calling @b{invoke-debugger}, @b{error} cannot directly return; the only exit from @b{error} can come by non-local transfer of control in a handler or by use of an interactive debugging command. @subsubheading Examples:: @example (defun factorial (x) (cond ((or (not (typep x 'integer)) (minusp x)) (error "~S is not a valid argument to FACTORIAL." x)) ((zerop x) 1) (t (* x (factorial (- x 1)))))) @result{} FACTORIAL (factorial 20) @result{} 2432902008176640000 (factorial -1) @t{ |> } Error: -1 is not a valid argument to FACTORIAL. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Return to Lisp Toplevel. @t{ |> } Debug> @end example @example (setq a 'fred) @result{} FRED (if (numberp a) (1+ a) (error "~S is not a number." A)) @t{ |> } Error: FRED is not a number. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{:Continue 1}@b{<<|} @t{ |> } Return to Lisp Toplevel. (define-condition not-a-number (error) ((argument :reader not-a-number-argument :initarg :argument)) (:report (lambda (condition stream) (format stream "~S is not a number." (not-a-number-argument condition))))) @result{} NOT-A-NUMBER (if (numberp a) (1+ a) (error 'not-a-number :argument a)) @t{ |> } Error: FRED is not a number. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{:Continue 1}@b{<<|} @t{ |> } Return to Lisp Toplevel. @end example @subsubheading Side Effects:: @i{Handlers} for the specified condition, if any, are invoked and might have side effects. Program execution might stop, and the debugger might be entered. @subsubheading Affected By:: Existing handler bindings. @b{*break-on-signals*} Signals an error of @i{type} @b{type-error} if @i{datum} and @i{arguments} are not @i{designators} for a @i{condition}. @subsubheading See Also:: @ref{cerror} , @ref{signal} , @ref{format} , @ref{ignore-errors} , @b{*break-on-signals*}, @ref{handler-bind} , @ref{Condition System Concepts} @subsubheading Notes:: Some implementations may provide debugger commands for interactively returning from individual stack frames. However, it should be possible for the programmer to feel confident about writing code like: @example (defun wargames:no-win-scenario () (if (error "pushing the button would be stupid.")) (push-the-button)) @end example In this scenario, there should be no chance that @b{error} will return and the button will get pushed. While the meaning of this program is clear and it might be proven `safe' by a formal theorem prover, such a proof is no guarantee that the program is safe to execute. Compilers have been known to have bugs, computers to have signal glitches, and human beings to manually intervene in ways that are not always possible to predict. Those kinds of errors, while beyond the scope of the condition system to formally model, are not beyond the scope of things that should seriously be considered when writing code that could have the kinds of sweeping effects hinted at by this example. @node cerror, check-type, error, Conditions Dictionary @subsection cerror [Function] @code{cerror} @i{continue-format-control datum {&rest} arguments} @result{} @i{@b{nil}} @subsubheading Arguments and Values:: @i{Continue-format-control}---a @i{format control}. [Reviewer Note by Barmar: What is continue-format-control used for??] @i{datum}, @i{arguments}---@i{designators} for a @i{condition} of default type @b{simple-error}. @subsubheading Description:: @b{cerror} effectively invokes @b{error} on the @i{condition} named by @i{datum}. As with any function that implicitly calls @b{error}, if the @i{condition} is not handled, @t{(invoke-debugger @i{condition})} is executed. While signaling is going on, and while in the debugger if it is reached, it is possible to continue code execution (@i{i.e.}, to return from @b{cerror}) using the @b{continue} @i{restart}. If @i{datum} is a @i{condition}, @i{arguments} can be supplied, but are used only in conjunction with the @i{continue-format-control}. @subsubheading Examples:: @example (defun real-sqrt (n) (when (minusp n) (setq n (- n)) (cerror "Return sqrt(~D) instead." "Tried to take sqrt(-~D)." n)) (sqrt n)) (real-sqrt 4) @result{} 2.0 (real-sqrt -9) @t{ |> } Correctable error in REAL-SQRT: Tried to take sqrt(-9). @t{ |> } Restart options: @t{ |> } 1: Return sqrt(9) instead. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @result{} 3.0 (define-condition not-a-number (error) ((argument :reader not-a-number-argument :initarg :argument)) (:report (lambda (condition stream) (format stream "~S is not a number." (not-a-number-argument condition))))) (defun assure-number (n) (loop (when (numberp n) (return n)) (cerror "Enter a number." 'not-a-number :argument n) (format t "~&Type a number: ") (setq n (read)) (fresh-line))) (assure-number 'a) @t{ |> } Correctable error in ASSURE-NUMBER: A is not a number. @t{ |> } Restart options: @t{ |> } 1: Enter a number. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @t{ |> } Type a number: @b{|>>}@t{1/2}@b{<<|} @result{} 1/2 (defun assure-large-number (n) (loop (when (and (numberp n) (> n 73)) (return n)) (cerror "Enter a number~:[~; a bit larger than ~D~]." "~*~A is not a large number." (numberp n) n) (format t "~&Type a large number: ") (setq n (read)) (fresh-line))) (assure-large-number 10000) @result{} 10000 (assure-large-number 'a) @t{ |> } Correctable error in ASSURE-LARGE-NUMBER: A is not a large number. @t{ |> } Restart options: @t{ |> } 1: Enter a number. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @t{ |> } Type a large number: @b{|>>}@t{88}@b{<<|} @result{} 88 (assure-large-number 37) @t{ |> } Correctable error in ASSURE-LARGE-NUMBER: 37 is not a large number. @t{ |> } Restart options: @t{ |> } 1: Enter a number a bit larger than 37. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @t{ |> } Type a large number: @b{|>>}@t{259}@b{<<|} @result{} 259 (define-condition not-a-large-number (error) ((argument :reader not-a-large-number-argument :initarg :argument)) (:report (lambda (condition stream) (format stream "~S is not a large number." (not-a-large-number-argument condition))))) (defun assure-large-number (n) (loop (when (and (numberp n) (> n 73)) (return n)) (cerror "Enter a number~3*~:[~; a bit larger than ~*~D~]." 'not-a-large-number :argument n :ignore (numberp n) :ignore n :allow-other-keys t) (format t "~&Type a large number: ") (setq n (read)) (fresh-line))) (assure-large-number 'a) @t{ |> } Correctable error in ASSURE-LARGE-NUMBER: A is not a large number. @t{ |> } Restart options: @t{ |> } 1: Enter a number. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @t{ |> } Type a large number: @b{|>>}@t{88}@b{<<|} @result{} 88 (assure-large-number 37) @t{ |> } Correctable error in ASSURE-LARGE-NUMBER: A is not a large number. @t{ |> } Restart options: @t{ |> } 1: Enter a number a bit larger than 37. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @t{ |> } Type a large number: @b{|>>}@t{259}@b{<<|} @result{} 259 @end example @subsubheading Affected By:: @b{*break-on-signals*}. Existing handler bindings. @subsubheading See Also:: @ref{error} , @ref{format} , @ref{handler-bind} , @b{*break-on-signals*}, @b{simple-type-error} @subsubheading Notes:: If @i{datum} is a @i{condition} @i{type} rather than a @i{string}, the @b{format} directive @t{~*} may be especially useful in the @i{continue-format-control} in order to ignore the @i{keywords} in the @i{initialization argument list}. For example: @example (cerror "enter a new value to replace ~*~s" 'not-a-number :argument a) @end example @node check-type, simple-error, cerror, Conditions Dictionary @subsection check-type [Macro] @code{check-type} @i{place typespec {@r{[}@i{string}@r{]}}} @result{} @i{@b{nil}} @subsubheading Arguments and Values:: @i{place}---a @i{place}. @i{typespec}---a @i{type specifier}. @i{string}---a @i{string}; evaluated. @subsubheading Description:: @b{check-type} signals a @i{correctable} @i{error} of @i{type} @b{type-error} if the contents of @i{place} are not of the type @i{typespec}. @b{check-type} can return only if the @b{store-value} @i{restart} is invoked, either explicitly from a handler or implicitly as one of the options offered by the debugger. If the @b{store-value} @i{restart} is invoked, @b{check-type} stores the new value that is the argument to the @i{restart} invocation (or that is prompted for interactively by the debugger) in @i{place} and starts over, checking the type of the new value and signaling another error if it is still not of the desired @i{type}. The first time @i{place} is @i{evaluated}, it is @i{evaluated} by normal evaluation rules. It is later @i{evaluated} as a @i{place} if the type check fails and the @b{store-value} @i{restart} is used; see @ref{Evaluation of Subforms to Places}. @i{string} should be an English description of the type, starting with an indefinite article (``a'' or ``an''). If @i{string} is not supplied, it is computed automatically from @i{typespec}. The automatically generated message mentions @i{place}, its contents, and the desired type. An implementation may choose to generate a somewhat differently worded error message if it recognizes that @i{place} is of a particular form, such as one of the arguments to the function that called @b{check-type}. @i{string} is allowed because some applications of @b{check-type} may require a more specific description of what is wanted than can be generated automatically from @i{typespec}. @subsubheading Examples:: @example (setq aardvarks '(sam harry fred)) @result{} (SAM HARRY FRED) (check-type aardvarks (array * (3))) @t{ |> } Error: The value of AARDVARKS, (SAM HARRY FRED), @t{ |> } is not a 3-long array. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Specify a value to use instead. @t{ |> } 2: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{:CONTINUE 1}@b{<<|} @t{ |> } Use Value: @b{|>>}@t{#(SAM FRED HARRY)}@b{<<|} @result{} NIL aardvarks @result{} # (map 'list #'identity aardvarks) @result{} (SAM FRED HARRY) (setq aardvark-count 'foo) @result{} FOO (check-type aardvark-count (integer 0 *) "A positive integer") @t{ |> } Error: The value of AARDVARK-COUNT, FOO, is not a positive integer. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Specify a value to use instead. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:CONTINUE 2}@b{<<|} @end example @example (defmacro define-adder (name amount) (check-type name (and symbol (not null)) "a name for an adder function") (check-type amount integer) `(defun ,name (x) (+ x ,amount))) (macroexpand '(define-adder add3 3)) @result{} (defun add3 (x) (+ x 3)) (macroexpand '(define-adder 7 7)) @t{ |> } Error: The value of NAME, 7, is not a name for an adder function. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Specify a value to use instead. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:Continue 1}@b{<<|} @t{ |> } Specify a value to use instead. @t{ |> } Type a form to be evaluated and used instead: @b{|>>}@t{'ADD7}@b{<<|} @result{} (defun add7 (x) (+ x 7)) (macroexpand '(define-adder add5 something)) @t{ |> } Error: The value of AMOUNT, SOMETHING, is not an integer. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Specify a value to use instead. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:Continue 1}@b{<<|} @t{ |> } Type a form to be evaluated and used instead: @b{|>>}@t{5}@b{<<|} @result{} (defun add5 (x) (+ x 5)) @end example Control is transferred to a handler. @subsubheading Side Effects:: The debugger might be entered. @subsubheading Affected By:: @b{*break-on-signals*} The implementation. @subsubheading See Also:: @ref{Condition System Concepts} @subsubheading Notes:: @example (check-type @i{place} @i{typespec}) @equiv{} (assert (typep @i{place} '@i{typespec}) (@i{place}) 'type-error :datum @i{place} :expected-type '@i{typespec}) @end example @node simple-error, invalid-method-error, check-type, Conditions Dictionary @subsection simple-error [Condition Type] @subsubheading Class Precedence List:: @b{simple-error}, @b{simple-condition}, @b{error}, @b{serious-condition}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{simple-error} consists of @i{conditions} that are signaled by @b{error} or @b{cerror} when a @i{format control} is supplied as the function's first argument. @node invalid-method-error, method-combination-error, simple-error, Conditions Dictionary @subsection invalid-method-error [Function] @code{invalid-method-error} @i{method format-control {&rest} args} @result{} @i{@i{implementation-dependent}} @subsubheading Arguments and Values:: @i{method}---a @i{method}. @i{format-control}---a @i{format control}. @i{args}---@i{format arguments} for the @i{format-control}. @subsubheading Description:: The @i{function} @b{invalid-method-error} is used to signal an error of @i{type} @b{error} when there is an applicable @i{method} whose @i{qualifiers} are not valid for the method combination type. The error message is constructed by using the @i{format-control} suitable for @b{format} and any @i{args} to it. Because an implementation may need to add additional contextual information to the error message, @b{invalid-method-error} should be called only within the dynamic extent of a method combination function. The @i{function} @b{invalid-method-error} is called automatically when a @i{method} fails to satisfy every @i{qualifier} pattern and predicate in a @b{define-method-combination} @i{form}. A method combination function that imposes additional restrictions should call @b{invalid-method-error} explicitly if it encounters a @i{method} it cannot accept. Whether @b{invalid-method-error} returns to its caller or exits via @b{throw} is @i{implementation-dependent}. @subsubheading Side Effects:: The debugger might be entered. @subsubheading Affected By:: @b{*break-on-signals*} @subsubheading See Also:: @ref{define-method-combination} @node method-combination-error, signal, invalid-method-error, Conditions Dictionary @subsection method-combination-error [Function] @code{method-combination-error} @i{format-control {&rest} args} @result{} @i{@i{implementation-dependent}} @subsubheading Arguments and Values:: @i{format-control}---a @i{format control}. @i{args}---@i{format arguments} for @i{format-control}. @subsubheading Description:: The @i{function} @b{method-combination-error} is used to signal an error in method combination. The error message is constructed by using a @i{format-control} suitable for @b{format} and any @i{args} to it. Because an implementation may need to add additional contextual information to the error message, @b{method-combination-error} should be called only within the dynamic extent of a method combination function. Whether @b{method-combination-error} returns to its caller or exits via @b{throw} is @i{implementation-dependent}. @subsubheading Side Effects:: The debugger might be entered. @subsubheading Affected By:: @b{*break-on-signals*} @subsubheading See Also:: @ref{define-method-combination} @node signal, simple-condition, method-combination-error, Conditions Dictionary @subsection signal [Function] @code{signal} @i{datum {&rest} arguments} @result{} @i{@b{nil}} @subsubheading Arguments and Values:: @i{datum}, @i{arguments}---@i{designators} for a @i{condition} of default type @b{simple-condition}. @subsubheading Description:: @i{Signals} the @i{condition} denoted by the given @i{datum} and @i{arguments}. If the @i{condition} is not handled, @b{signal} returns @b{nil}. @subsubheading Examples:: @example (defun handle-division-conditions (condition) (format t "Considering condition for division condition handling~ (when (and (typep condition 'arithmetic-error) (eq '/ (arithmetic-error-operation condition))) (invoke-debugger condition))) HANDLE-DIVISION-CONDITIONS (defun handle-other-arithmetic-errors (condition) (format t "Considering condition for arithmetic condition handling~ (when (typep condition 'arithmetic-error) (abort))) HANDLE-OTHER-ARITHMETIC-ERRORS (define-condition a-condition-with-no-handler (condition) ()) A-CONDITION-WITH-NO-HANDLER (signal 'a-condition-with-no-handler) NIL (handler-bind ((condition #'handle-division-conditions) (condition #'handle-other-arithmetic-errors)) (signal 'a-condition-with-no-handler)) Considering condition for division condition handling Considering condition for arithmetic condition handling NIL (handler-bind ((arithmetic-error #'handle-division-conditions) (arithmetic-error #'handle-other-arithmetic-errors)) (signal 'arithmetic-error :operation '* :operands '(1.2 b))) Considering condition for division condition handling Considering condition for arithmetic condition handling Back to Lisp Toplevel @end example @subsubheading Side Effects:: The debugger might be entered due to @b{*break-on-signals*}. Handlers for the condition being signaled might transfer control. @subsubheading Affected By:: Existing handler bindings. @b{*break-on-signals*} @subsubheading See Also:: @b{*break-on-signals*}, @ref{error} , @b{simple-condition}, @ref{Signaling and Handling Conditions} @subsubheading Notes:: If @t{(typep @i{datum} *break-on-signals*)} @i{yields} @i{true}, the debugger is entered prior to beginning the signaling process. The @b{continue} @i{restart} can be used to continue with the signaling process. This is also true for all other @i{functions} and @i{macros} that should, might, or must @i{signal} @i{conditions}. @node simple-condition, simple-condition-format-control, signal, Conditions Dictionary @subsection simple-condition [Condition Type] @subsubheading Class Precedence List:: @b{simple-condition}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{simple-condition} represents @i{conditions} that are signaled by @b{signal} whenever a @i{format-control} is supplied as the function's first argument. The @i{format control} and @i{format arguments} are initialized with the initialization arguments named @t{:format-control} and @t{:format-arguments} to @b{make-condition}, and are @i{accessed} by the @i{functions} @b{simple-condition-format-control} and @b{simple-condition-format-arguments}. If format arguments are not supplied to @b{make-condition}, @b{nil} is used as a default. @subsubheading See Also:: @ref{simple-condition-format-control; simple-condition-format-arguments} , @b{simple-condition-format-arguments} @node simple-condition-format-control, warn, simple-condition, Conditions Dictionary @subsection simple-condition-format-control, simple-condition-format-arguments @flushright @i{[Function]} @end flushright @code{simple-condition-format-control} @i{condition} @result{} @i{format-control} @code{simple-condition-format-arguments} @i{condition} @result{} @i{format-arguments} @subsubheading Arguments and Values:: @i{condition}---a @i{condition} of @i{type} @b{simple-condition}. @i{format-control}---a @i{format control}. @i{format-arguments}---a @i{list}. @subsubheading Description:: @b{simple-condition-format-control} returns the @i{format control} needed to process the @i{condition}'s @i{format arguments}. @b{simple-condition-format-arguments} returns a @i{list} of @i{format arguments} needed to process the @i{condition}'s @i{format control}. @subsubheading Examples:: @example (setq foo (make-condition 'simple-condition :format-control "Hi ~S" :format-arguments '(ho))) @result{} # (apply #'format nil (simple-condition-format-control foo) (simple-condition-format-arguments foo)) @result{} "Hi HO" @end example @subsubheading See Also:: @ref{simple-condition} , @ref{Condition System Concepts} @node warn, simple-warning, simple-condition-format-control, Conditions Dictionary @subsection warn [Function] @code{warn} @i{datum {&rest} arguments} @result{} @i{@b{nil}} @subsubheading Arguments and Values:: @i{datum}, @i{arguments}---@i{designators} for a @i{condition} of default type @b{simple-warning}. @subsubheading Description:: @i{Signals} a @i{condition} of @i{type} @b{warning}. If the @i{condition} is not @i{handled}, reports the @i{condition} to @i{error output}. The precise mechanism for warning is as follows: @table @asis @item @b{The warning condition is signaled} While the @b{warning} @i{condition} is being signaled, the @b{muffle-warning} @i{restart} is established for use by a @i{handler}. If invoked, this @i{restart} bypasses further action by @b{warn}, which in turn causes @b{warn} to immediately return @b{nil}. @item @b{If no handler for the warning condition is found} If no handlers for the warning condition are found, or if all such handlers decline, then the @i{condition} is reported to @i{error output} by @b{warn} in an @i{implementation-dependent} format. @item @b{@b{nil} is returned} The value returned by @b{warn} if it returns is @b{nil}. @end table @subsubheading Examples:: @example (defun foo (x) (let ((result (* x 2))) (if (not (typep result 'fixnum)) (warn "You're using very big numbers.")) result)) @result{} FOO (foo 3) @result{} 6 (foo most-positive-fixnum) @t{ |> } Warning: You're using very big numbers. @result{} 4294967294 (setq *break-on-signals* t) @result{} T (foo most-positive-fixnum) @t{ |> } Break: Caveat emptor. @t{ |> } To continue, type :CONTINUE followed by an option number. @t{ |> } 1: Return from Break. @t{ |> } 2: Abort to Lisp Toplevel. @t{ |> } Debug> :continue 1 @t{ |> } Warning: You're using very big numbers. @result{} 4294967294 @end example @subsubheading Side Effects:: A warning is issued. The debugger might be entered. @subsubheading Affected By:: Existing handler bindings. @b{*break-on-signals*}, @b{*error-output*}. @subsubheading Exceptional Situations:: If @i{datum} is a @i{condition} and if the @i{condition} is not of @i{type} @b{warning}, or @i{arguments} is @i{non-nil}, an error of @i{type} @b{type-error} is signaled. If @i{datum} is a condition type, the result of @t{(apply #'make-condition datum arguments)} must be of @i{type} @b{warning} or an error of @i{type} @b{type-error} is signaled. @subsubheading See Also:: @b{*break-on-signals*}, @ref{muffle-warning} , @ref{signal} @node simple-warning, invoke-debugger, warn, Conditions Dictionary @subsection simple-warning [Condition Type] @subsubheading Class Precedence List:: @b{simple-warning}, @b{simple-condition}, @b{warning}, @b{condition}, @b{t} @subsubheading Description:: The @i{type} @b{simple-warning} represents @i{conditions} that are signaled by @b{warn} whenever a @i{format control} is supplied as the function's first argument. @node invoke-debugger, break, simple-warning, Conditions Dictionary @subsection invoke-debugger [Function] @code{invoke-debugger} @i{condition} @result{} # @subsubheading Arguments and Values:: @i{condition}---a @i{condition} @i{object}. @subsubheading Description:: @b{invoke-debugger} attempts to enter the debugger with @i{condition}. If @b{*debugger-hook*} is not @b{nil}, it should be a @i{function} (or the name of a @i{function}) to be called prior to entry to the standard debugger. The @i{function} is called with @b{*debugger-hook*} bound to @b{nil}, and the @i{function} must accept two arguments: the @i{condition} and the @i{value} of @b{*debugger-hook*} prior to binding it to @b{nil}. If the @i{function} returns normally, the standard debugger is entered. The standard debugger never directly returns. Return can occur only by a non-local transfer of control, such as the use of a restart function. @subsubheading Examples:: @example (ignore-errors ;Normally, this would suppress debugger entry (handler-bind ((error #'invoke-debugger)) ;But this forces debugger entry (error "Foo."))) Debug: Foo. To continue, type :CONTINUE followed by an option number: 1: Return to Lisp Toplevel. Debug> @end example @subsubheading Side Effects:: @b{*debugger-hook*} is bound to @b{nil}, program execution is discontinued, and the debugger is entered. @subsubheading Affected By:: @b{*debug-io*} and @b{*debugger-hook*}. @subsubheading See Also:: @ref{error} , @ref{break} @node break, *debugger-hook*, invoke-debugger, Conditions Dictionary @subsection break [Function] @code{break} @i{{&optional} format-control {&rest} format-arguments} @result{} @i{@b{nil}} @subsubheading Arguments and Values:: @i{format-control}---a @i{format control}. The default is @i{implementation-dependent}. @i{format-arguments}---@i{format arguments} for the @i{format-control}. @subsubheading Description:: @b{break} @i{formats} @i{format-control} and @i{format-arguments} and then goes directly into the debugger without allowing any possibility of interception by programmed error-handling facilities. If the @b{continue} @i{restart} is used while in the debugger, @b{break} immediately returns @b{nil} without taking any unusual recovery action. @b{break} binds @b{*debugger-hook*} to @b{nil} before attempting to enter the debugger. @subsubheading Examples:: @example (break "You got here with arguments: ~:S." '(FOO 37 A)) @t{ |> } BREAK: You got here with these arguments: FOO, 37, A. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Return from BREAK. @t{ |> } 2: Top level. @t{ |> } Debug> :CONTINUE 1 @t{ |> } Return from BREAK. @result{} NIL @end example @subsubheading Side Effects:: The debugger is entered. @subsubheading Affected By:: @b{*debug-io*}. @subsubheading See Also:: @ref{error} , @ref{invoke-debugger} . @subsubheading Notes:: @b{break} is used as a way of inserting temporary debugging ``breakpoints'' in a program, not as a way of signaling errors. For this reason, @b{break} does not take the @i{continue-format-control} @i{argument} that @b{cerror} takes. This and the lack of any possibility of interception by @i{condition} @i{handling} are the only program-visible differences between @b{break} and @b{cerror}. The user interface aspects of @b{break} and @b{cerror} are permitted to vary more widely, in order to accomodate the interface needs of the @i{implementation}. For example, it is permissible for a @i{Lisp read-eval-print loop} to be entered by @b{break} rather than the conventional debugger. @b{break} could be defined by: @example (defun break (&optional (format-control "Break") &rest format-arguments) (with-simple-restart (continue "Return from BREAK.") (let ((*debugger-hook* nil)) (invoke-debugger (make-condition 'simple-condition :format-control format-control :format-arguments format-arguments)))) nil) @end example @node *debugger-hook*, *break-on-signals*, break, Conditions Dictionary @subsection *debugger-hook* [Variable] @subsubheading Value Type:: a @i{designator} for a @i{function} of two @i{arguments} (a @i{condition} and the @i{value} of @b{*debugger-hook*} at the time the debugger was entered), or @b{nil}. @subsubheading Initial Value:: @b{nil}. @subsubheading Description:: When the @i{value} of @b{*debugger-hook*} is @i{non-nil}, it is called prior to normal entry into the debugger, either due to a call to @b{invoke-debugger} or due to automatic entry into the debugger from a call to @b{error} or @b{cerror} with a condition that is not handled. The @i{function} may either handle the @i{condition} (transfer control) or return normally (allowing the standard debugger to run). To minimize recursive errors while debugging, @b{*debugger-hook*} is bound to @b{nil} by @b{invoke-debugger} prior to calling the @i{function}. @subsubheading Examples:: @example (defun one-of (choices &optional (prompt "Choice")) (let ((n (length choices)) (i)) (do ((c choices (cdr c)) (i 1 (+ i 1))) ((null c)) (format t "~&[~D] ~A~ (do () ((typep i `(integer 1 ,n))) (format t "~&~A: " prompt) (setq i (read)) (fresh-line)) (nth (- i 1) choices))) (defun my-debugger (condition me-or-my-encapsulation) (format t "~&Fooey: ~A" condition) (let ((restart (one-of (compute-restarts)))) (if (not restart) (error "My debugger got an error.")) (let ((*debugger-hook* me-or-my-encapsulation)) (invoke-restart-interactively restart)))) (let ((*debugger-hook* #'my-debugger)) (+ 3 'a)) @t{ |> } Fooey: The argument to +, A, is not a number. @t{ |> } [1] Supply a replacement for A. @t{ |> } [2] Return to Cloe Toplevel. @t{ |> } Choice: 1 @t{ |> } Form to evaluate and use: (+ 5 'b) @t{ |> } Fooey: The argument to +, B, is not a number. @t{ |> } [1] Supply a replacement for B. @t{ |> } [2] Supply a replacement for A. @t{ |> } [3] Return to Cloe Toplevel. @t{ |> } Choice: 1 @t{ |> } Form to evaluate and use: 1 @result{} 9 @end example @subsubheading Affected By:: @b{invoke-debugger} @subsubheading Notes:: When evaluating code typed in by the user interactively, it is sometimes useful to have the hook function bind @b{*debugger-hook*} to the @i{function} that was its second argument so that recursive errors can be handled using the same interactive facility. @node *break-on-signals*, handler-bind, *debugger-hook*, Conditions Dictionary @subsection *break-on-signals* [Variable] @subsubheading Value Type:: a @i{type specifier}. @subsubheading Initial Value:: @b{nil}. @subsubheading Description:: When @t{(typep @i{condition} *break-on-signals*)} returns @i{true}, calls to @b{signal}, and to other @i{operators} such as @b{error} that implicitly call @b{signal}, enter the debugger prior to @i{signaling} the @i{condition}. The @b{continue} @i{restart} can be used to continue with the normal @i{signaling} process when a break occurs process due to @b{*break-on-signals*}. @subsubheading Examples:: @example *break-on-signals* @result{} NIL (ignore-errors (error 'simple-error :format-control "Fooey!")) @result{} NIL, # (let ((*break-on-signals* 'error)) (ignore-errors (error 'simple-error :format-control "Fooey!"))) @t{ |> } Break: Fooey! @t{ |> } BREAK entered because of *BREAK-ON-SIGNALS*. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Continue to signal. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:CONTINUE 1}@b{<<|} @t{ |> } Continue to signal. @result{} NIL, # (let ((*break-on-signals* 'error)) (error 'simple-error :format-control "Fooey!")) @t{ |> } Break: Fooey! @t{ |> } BREAK entered because of *BREAK-ON-SIGNALS*. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Continue to signal. @t{ |> } 2: Top level. @t{ |> } Debug> @b{|>>}@t{:CONTINUE 1}@b{<<|} @t{ |> } Continue to signal. @t{ |> } Error: Fooey! @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Top level. @t{ |> } Debug> @b{|>>}@t{:CONTINUE 1}@b{<<|} @t{ |> } Top level. @end example @subsubheading See Also:: @ref{break} , @ref{signal} , @ref{warn} , @ref{error} , @ref{typep} , @ref{Condition System Concepts} @subsubheading Notes:: @b{*break-on-signals*} is intended primarily for use in debugging code that does signaling. When setting @b{*break-on-signals*}, the user is encouraged to choose the most restrictive specification that suffices. Setting @b{*break-on-signals*} effectively violates the modular handling of @i{condition} signaling. In practice, the complete effect of setting @b{*break-on-signals*} might be unpredictable in some cases since the user might not be aware of the variety or number of calls to @b{signal} that are used in code called only incidentally. @b{*break-on-signals*} enables an early entry to the debugger but such an entry does not preclude an additional entry to the debugger in the case of operations such as @b{error} and @b{cerror}. @node handler-bind, handler-case, *break-on-signals*, Conditions Dictionary @subsection handler-bind [Macro] @code{handler-bind} @i{@r{(}@{!@i{binding}@}{*}@r{)} @{@i{form}@}{*}} @result{} @i{@{@i{result}@}{*}} @w{@i{binding} ::=@r{(}type handler@r{)}} @subsubheading Arguments and Values:: @i{type}---a @i{type specifier}. @i{handler}---a @i{form}; evaluated to produce a @i{handler-function}. @i{handler-function}---a @i{designator} for a @i{function} of one @i{argument}. @i{forms}---an @i{implicit progn}. @i{results}---the @i{values} returned by the @i{forms}. @subsubheading Description:: Executes @i{forms} in a @i{dynamic environment} where the indicated @i{handler} @i{bindings} are in effect. Each @i{handler} should evaluate to a @i{handler-function}, which is used to handle @i{conditions} of the given @i{type} during execution of the @i{forms}. This @i{function} should take a single argument, the @i{condition} being signaled. If more than one @i{handler} @i{binding} is supplied, the @i{handler} @i{bindings} are searched sequentially from top to bottom in search of a match (by visual analogy with @b{typecase}). If an appropriate @i{type} is found, the associated handler is run in a @i{dynamic environment} where none of these @i{handler} bindings are visible (to avoid recursive errors). If the @i{handler} @i{declines}, the search continues for another @i{handler}. If no appropriate @i{handler} is found, other @i{handlers} are sought from dynamically enclosing contours. If no @i{handler} is found outside, then @b{signal} returns or @b{error} enters the debugger. @subsubheading Examples:: In the following code, if an unbound variable error is signaled in the body (and not handled by an intervening handler), the first function is called. @example (handler-bind ((unbound-variable #'(lambda ...)) (error #'(lambda ...))) ...) @end example If any other kind of error is signaled, the second function is called. In either case, neither handler is active while executing the code in the associated function. @example (defun trap-error-handler (condition) (format *error-output* "~&~A~&" condition) (throw 'trap-errors nil)) (defmacro trap-errors (&rest forms) `(catch 'trap-errors (handler-bind ((error #'trap-error-handler)) ,@@forms))) (list (trap-errors (signal "Foo.") 1) (trap-errors (error "Bar.") 2) (+ 1 2)) @t{ |> } Bar. @result{} (1 NIL 3) @end example Note that ``Foo.'' is not printed because the condition made by @b{signal} is a @i{simple condition}, which is not of @i{type} @b{error}, so it doesn't trigger the handler for @b{error} set up by @t{trap-errors}. @subsubheading See Also:: @ref{handler-case} @node handler-case, ignore-errors, handler-bind, Conditions Dictionary @subsection handler-case [Macro] @code{handler-case} @i{@i{expression} [[@{!@i{error-clause}@}{*} | !@i{no-error-clause}]]} @result{} @i{@{@i{result}@}{*}} @w{@i{clause} ::=!@i{error-clause} | !@i{no-error-clause}} @w{@i{error-clause} ::=@r{(}typespec @r{(}@t{[}var@t{]}@r{)} @{@i{declaration}@}{*} @{@i{form}@}{*}@r{)}} @w{@i{no-error-clause} ::=@r{(}@t{:no-error} @i{lambda-list} @{@i{declaration}@}{*} @{@i{form}@}{*}@r{)}} @subsubheading Arguments and Values:: @i{expression}---a @i{form}. @i{typespec}---a @i{type specifier}. @i{var}---a @i{variable} @i{name}. @i{lambda-list}---an @i{ordinary lambda list}. @i{declaration}---a @b{declare} @i{expression}; not evaluated. @i{form}---a @i{form}. @i{results}---In the normal situation, the values returned are those that result from the evaluation of @i{expression}; in the exceptional situation when control is transferred to a @i{clause}, the value of the last @i{form} in that @i{clause} is returned. @subsubheading Description:: @b{handler-case} executes @i{expression} in a @i{dynamic environment} where various handlers are active. Each @i{error-clause} specifies how to handle a @i{condition} matching the indicated @i{typespec}. A @i{no-error-clause} allows the specification of a particular action if control returns normally. If a @i{condition} is signaled for which there is an appropriate @i{error-clause} during the execution of @i{expression} (@i{i.e.}, one for which @t{(typep @i{condition} '@i{typespec})} returns @i{true}) and if there is no intervening handler for a @i{condition} of that @i{type}, then control is transferred to the body of the relevant @i{error-clause}. In this case, the dynamic state is unwound appropriately (so that the handlers established around the @i{expression} are no longer active), and @i{var} is bound to the @i{condition} that had been signaled. If more than one case is provided, those cases are made accessible in parallel. That is, in @example (handler-case @i{form} (@i{typespec1} (@i{var1}) @i{form1}) (@i{typespec2} (@i{var2}) @i{form2})) @end example if the first @i{clause} (containing @i{form1}) has been selected, the handler for the second is no longer visible (or vice versa). The @i{clauses} are searched sequentially from top to bottom. If there is @i{type} overlap between @i{typespecs}, the earlier of the @i{clauses} is selected. If @i{var} is not needed, it can be omitted. That is, a @i{clause} such as: @example (@i{typespec} (@i{var}) (declare (ignore @i{var})) @i{form}) @end example can be written @t{(@i{typespec} () @i{form})}. If there are no @i{forms} in a selected @i{clause}, the case, and therefore @b{handler-case}, returns @b{nil}. If execution of @i{expression} returns normally and no @i{no-error-clause} exists, the values returned by @i{expression} are returned by @b{handler-case}. If execution of @i{expression} returns normally and a @i{no-error-clause} does exist, the values returned are used as arguments to the function described by constructing @t{(lambda @i{lambda-list} @{@i{form}@}{*})} from the @i{no-error-clause}, and the @i{values} of that function call are returned by @b{handler-case}. The handlers which were established around the @i{expression} are no longer active at the time of this call. @subsubheading Examples:: @example (defun assess-condition (condition) (handler-case (signal condition) (warning () "Lots of smoke, but no fire.") ((or arithmetic-error control-error cell-error stream-error) (condition) (format nil "~S looks especially bad." condition)) (serious-condition (condition) (format nil "~S looks serious." condition)) (condition () "Hardly worth mentioning."))) @result{} ASSESS-CONDITION (assess-condition (make-condition 'stream-error :stream *terminal-io*)) @result{} "# looks especially bad." (define-condition random-condition (condition) () (:report (lambda (condition stream) (declare (ignore condition)) (princ "Yow" stream)))) @result{} RANDOM-CONDITION (assess-condition (make-condition 'random-condition)) @result{} "Hardly worth mentioning." @end example @subsubheading See Also:: @ref{handler-bind} , @ref{ignore-errors} , @ref{Condition System Concepts} @subsubheading Notes:: @example (handler-case form (@i{type1} (@i{var1}) . @i{body1}) (@i{type2} (@i{var2}) . @i{body2}) ...) @end example is approximately equivalent to: @example (block #1=#:g0001 (let ((#2=#:g0002 nil)) (tagbody (handler-bind ((@i{type1} #'(lambda (temp) (setq #1# temp) (go #3=#:g0003))) (@i{type2} #'(lambda (temp) (setq #2# temp) (go #4=#:g0004))) ...) (return-from #1# form)) #3# (return-from #1# (let ((@i{var1} #2#)) . @i{body1})) #4# (return-from #1# (let ((@i{var2} #2#)) . @i{body2})) ...))) @end example @example (handler-case form (@i{type1} @i{(var1)} . @i{body1}) ... (:no-error (@i{varN-1} @i{varN-2} ...) . @i{bodyN})) @end example is approximately equivalent to: @example (block #1=#:error-return (multiple-value-call #'(lambda (@i{varN-1} @i{varN-2} ...) . @i{bodyN}) (block #2=#:normal-return (return-from #1# (handler-case (return-from #2# form) (@i{type1} (@i{var1}) . @i{body1}) ...))))) @end example @node ignore-errors, define-condition, handler-case, Conditions Dictionary @subsection ignore-errors [Macro] @code{ignore-errors} @i{@{@i{form}@}{*}} @result{} @i{@{@i{result}@}{*}} @subsubheading Arguments and Values:: @i{forms}---an @i{implicit progn}. @i{results}---In the normal situation, the @i{values} of the @i{forms} are returned; in the exceptional situation, two values are returned: @b{nil} and the @i{condition}. @subsubheading Description:: @b{ignore-errors} is used to prevent @i{conditions} of @i{type} @b{error} from causing entry into the debugger. Specifically, @b{ignore-errors} @i{executes} @i{forms} in a @i{dynamic environment} where a @i{handler} for @i{conditions} of @i{type} @b{error} has been established; if invoked, it @i{handles} such @i{conditions} by returning two @i{values}, @b{nil} and the @i{condition} that was @i{signaled}, from the @b{ignore-errors} @i{form}. If a @i{normal return} from the @i{forms} occurs, any @i{values} returned are returned by @b{ignore-errors}. @subsubheading Examples:: @example (defun load-init-file (program) (let ((win nil)) (ignore-errors ;if this fails, don't enter debugger (load (merge-pathnames (make-pathname :name program :type :lisp) (user-homedir-pathname))) (setq win t)) (unless win (format t "~&Init file failed to load.~ win)) (load-init-file "no-such-program") @t{ |> } Init file failed to load. NIL @end example @subsubheading See Also:: @ref{handler-case} , @ref{Condition System Concepts} @subsubheading Notes:: @example (ignore-errors . @i{forms}) @end example is equivalent to: @example (handler-case (progn . @i{forms}) (error (condition) (values nil condition))) @end example Because the second return value is a @i{condition} in the exceptional case, it is common (but not required) to arrange for the second return value in the normal case to be missing or @b{nil} so that the two situations can be distinguished. @node define-condition, make-condition, ignore-errors, Conditions Dictionary @subsection define-condition [Macro] [Editorial Note by KMP: This syntax stuff is still very confused and needs lots of work.] @code{define-condition} @i{name @r{(}@{@i{parent-type}@}{*}@r{)} @r{(}@{!@i{slot-spec}@}{*}@r{)} @{@i{option}@}{*}}@* @result{} @i{name} @w{@i{slot-spec} ::=slot-name | @r{(}slot-name !@i{slot-option}@r{)}} @w{@i{slot-option} ::=[[ @{{:reader} @i{symbol}@}{*} | } @w{ @{{:writer} !@i{function-name}@}{*} | } @w{ @{{:accessor} @i{symbol}@}{*} | } @w{ @{{:allocation} !@i{allocation-type}@} | } @w{ @{{:initarg} @i{symbol}@}{*} | } @w{ @{{:initform} @i{form}@} | } @w{ @{{:type} @i{type-specifier}@} ]]} @w{@i{option} ::=[[ @r{(}@t{:default-initargs} @t{.} @i{initarg-list}@r{)} | } @w{ @r{(}@t{:documentation} @i{string}@r{)} | } @w{ @r{(}@t{:report} @i{report-name}@r{)} ]]} @w{@i{function-name} ::=@{@i{symbol} | @t{(setf @i{symbol})}@}} @w{@i{allocation-type} ::=@t{:instance} | @t{:class}} @w{@i{report-name} ::=@i{string} | @i{symbol} | @i{lambda expression}} @subsubheading Arguments and Values:: @i{name}---a @i{symbol}. @i{parent-type}---a @i{symbol} naming a @i{condition} @i{type}. If no @i{parent-types} are supplied, the @i{parent-types} default to @t{(condition)}. @i{default-initargs}---a @i{list} of @i{keyword/value pairs}. [Editorial Note by KMP: This is all mixed up as to which is a slot option and which is a main option. I'll sort that out. Also, some of this is implied by the bnf and needn't be stated explicitly.] @i{Slot-spec} -- the @i{name} of a @i{slot} or a @i{list} consisting of the @i{slot-name} followed by zero or more @i{slot-options}. @i{Slot-name} -- a slot name (a @i{symbol}), the @i{list} of a slot name, or the @i{list} of slot name/slot form pairs. @i{Option} -- Any of the following: @table @asis @item @t{:reader} @t{:reader} can be supplied more than once for a given @i{slot} and cannot be @b{nil}. @item @t{:writer} @t{:writer} can be supplied more than once for a given @i{slot} and must name a @i{generic function}. @item @t{:accessor} @t{:accessor} can be supplied more than once for a given @i{slot} and cannot be @b{nil}. @item @t{:allocation} @t{:allocation} can be supplied once at most for a given @i{slot}. The default if @t{:allocation} is not supplied is @t{:instance}. @item @t{:initarg} @t{:initarg} can be supplied more than once for a given @i{slot}. @item @t{:initform} @t{:initform} can be supplied once at most for a given @i{slot}. @item @t{:type} @t{:type} can be supplied once at most for a given @i{slot}. @item @t{:documentation} @t{:documentation} can be supplied once at most for a given @i{slot}. @item @t{:report} @t{:report} can be supplied once at most. @end table @subsubheading Description:: @b{define-condition} defines a new condition type called @i{name}, which is a @i{subtype} of the @i{type} or @i{types} named by @i{parent-type}. Each @i{parent-type} argument specifies a direct @i{supertype} of the new @i{condition}. The new @i{condition} inherits @i{slots} and @i{methods} from each of its direct @i{supertypes}, and so on. If a slot name/slot form pair is supplied, the slot form is a @i{form} that can be evaluated by @b{make-condition} to produce a default value when an explicit value is not provided. If no slot form is supplied, the contents of the @i{slot} is initialized in an @i{implementation-dependent} way. If the @i{type} being defined and some other @i{type} from which it inherits have a slot by the same name, only one slot is allocated in the @i{condition}, but the supplied slot form overrides any slot form that might otherwise have been inherited from a @i{parent-type}. If no slot form is supplied, the inherited slot form (if any) is still visible. Accessors are created according to the same rules as used by @b{defclass}. A description of @i{slot-options} follows: @table @asis @item @t{:reader} The @t{:reader} slot option specifies that an @i{unqualified method} is to be defined on the @i{generic function} named by the argument to @t{:reader} to read the value of the given @i{slot}. @item @t{*} The @t{:initform} slot option is used to provide a default initial value form to be used in the initialization of the @i{slot}. This @i{form} is evaluated every time it is used to initialize the @i{slot}. The @i{lexical environment} in which this @i{form} is evaluated is the lexical @i{environment} in which the @b{define-condition} form was evaluated. Note that the @i{lexical environment} refers both to variables and to @i{functions}. For @i{local slots}, the @i{dynamic environment} is the dynamic @i{environment} in which @b{make-condition} was called; for @i{shared slots}, the @i{dynamic environment} is the @i{dynamic environment} in which the @b{define-condition} form was evaluated. [Reviewer Note by Barmar: Issue CLOS-CONDITIONS doesn't say this.] No implementation is permitted to extend the syntax of @b{define-condition} to allow @t{(@i{slot-name} @i{form})} as an abbreviation for @t{(@i{slot-name} :initform @i{form})}. @item @t{:initarg} The @t{:initarg} slot option declares an initialization argument named by its @i{symbol} argument and specifies that this initialization argument initializes the given @i{slot}. If the initialization argument has a value in the call to @b{initialize-instance}, the value is stored into the given @i{slot}, and the slot's @t{:initform} slot option, if any, is not evaluated. If none of the initialization arguments specified for a given @i{slot} has a value, the @i{slot} is initialized according to the @t{:initform} slot option, if specified. @item @t{:type} The @t{:type} slot option specifies that the contents of the @i{slot} is always of the specified @i{type}. It effectively declares the result type of the reader generic function when applied to an @i{object} of this @i{condition} type. The consequences of attempting to store in a @i{slot} a value that does not satisfy the type of the @i{slot} is undefined. @item @t{:default-initargs} [Editorial Note by KMP: This is an option, not a slot option.] This option is treated the same as it would be @b{defclass}. @item @t{:documentation} [Editorial Note by KMP: This is both an option and a slot option.] The @t{:documentation} slot option provides a @i{documentation string} for the @i{slot}. @item @t{:report} [Editorial Note by KMP: This is an option, not a slot option.] @i{Condition} reporting is mediated through the @b{print-object} method for the @i{condition} type in question, with @b{*print-escape*} always being @b{nil}. Specifying @t{(:report @i{report-name})} in the definition of a condition type @t{C} is equivalent to: @example (defmethod print-object ((x c) stream) (if *print-escape* (call-next-method) (@i{report-name} x stream))) @end example If the value supplied by the argument to @t{:report} (@i{report-name}) is a @i{symbol} or a @i{lambda expression}, it must be acceptable to @b{function}. @t{(function @i{report-name})} is evaluated in the current @i{lexical environment}. It should return a @i{function} of two arguments, a @i{condition} and a @i{stream}, that prints on the @i{stream} a description of the @i{condition}. This @i{function} is called whenever the @i{condition} is printed while @b{*print-escape*} is @b{nil}. If @i{report-name} is a @i{string}, it is a shorthand for @example (lambda (condition stream) (declare (ignore condition)) (write-string @i{report-name} stream)) @end example This option is processed after the new @i{condition} type has been defined, so use of the @i{slot} accessors within the @t{:report} function is permitted. If this option is not supplied, information about how to report this type of @i{condition} is inherited from the @i{parent-type}. @end table The consequences are unspecifed if an attempt is made to @i{read} a @i{slot} that has not been explicitly initialized and that has not been given a default value. The consequences are unspecified if an attempt is made to assign the @i{slots} by using @b{setf}. If a @b{define-condition} @i{form} appears as a @i{top level form}, the @i{compiler} must make @i{name} recognizable as a valid @i{type} name, and it must be possible to reference the @i{condition} @i{type} as the @i{parent-type} of another @i{condition} @i{type} in a subsequent @b{define-condition} @i{form} in the @i{file} being compiled. @subsubheading Examples:: The following form defines a condition of @i{type} @t{peg/hole-mismatch} which inherits from a condition type called @t{blocks-world-error}: @example (define-condition peg/hole-mismatch (blocks-world-error) ((peg-shape :initarg :peg-shape :reader peg/hole-mismatch-peg-shape) (hole-shape :initarg :hole-shape :reader peg/hole-mismatch-hole-shape)) (:report (lambda (condition stream) (format stream "A ~A peg cannot go in a ~A hole." (peg/hole-mismatch-peg-shape condition) (peg/hole-mismatch-hole-shape condition))))) @end example The new type has slots @t{peg-shape} and @t{hole-shape}, so @b{make-condition} accepts @t{:peg-shape} and @t{:hole-shape} keywords. The @i{readers} @t{peg/hole-mismatch-peg-shape} and @t{peg/hole-mismatch-hole-shape} apply to objects of this type, as illustrated in the @t{:report} information. The following form defines a @i{condition} @i{type} named @t{machine-error} which inherits from @b{error}: @example (define-condition machine-error (error) ((machine-name :initarg :machine-name :reader machine-error-machine-name)) (:report (lambda (condition stream) (format stream "There is a problem with ~A." (machine-error-machine-name condition))))) @end example Building on this definition, a new error condition can be defined which is a subtype of @t{machine-error} for use when machines are not available: @example (define-condition machine-not-available-error (machine-error) () (:report (lambda (condition stream) (format stream "The machine ~A is not available." (machine-error-machine-name condition))))) @end example This defines a still more specific condition, built upon @t{machine-not-available-error}, which provides a slot initialization form for @t{machine-name} but which does not provide any new slots or report information. It just gives the @t{machine-name} slot a default initialization: @example (define-condition my-favorite-machine-not-available-error (machine-not-available-error) ((machine-name :initform "mc.lcs.mit.edu"))) @end example Note that since no @t{:report} clause was given, the information inherited from @t{machine-not-available-error} is used to report this type of condition. @example (define-condition ate-too-much (error) ((person :initarg :person :reader ate-too-much-person) (weight :initarg :weight :reader ate-too-much-weight) (kind-of-food :initarg :kind-of-food :reader :ate-too-much-kind-of-food))) @result{} ATE-TOO-MUCH (define-condition ate-too-much-ice-cream (ate-too-much) ((kind-of-food :initform 'ice-cream) (flavor :initarg :flavor :reader ate-too-much-ice-cream-flavor :initform 'vanilla )) (:report (lambda (condition stream) (format stream "~A ate too much ~A ice-cream" (ate-too-much-person condition) (ate-too-much-ice-cream-flavor condition))))) @result{} ATE-TOO-MUCH-ICE-CREAM (make-condition 'ate-too-much-ice-cream :person 'fred :weight 300 :flavor 'chocolate) @result{} # (format t "~A" *) @t{ |> } FRED ate too much CHOCOLATE ice-cream @result{} NIL @end example @subsubheading See Also:: @ref{make-condition} , @ref{defclass} , @ref{Condition System Concepts} @node make-condition, restart, define-condition, Conditions Dictionary @subsection make-condition [Function] @code{make-condition} @i{type {&rest} slot-initializations} @result{} @i{condition} @subsubheading Arguments and Values:: @i{type}---a @i{type specifier} (for a @i{subtype} of @b{condition}). @i{slot-initializations}---an @i{initialization argument list}. @i{condition}---a @i{condition}. @subsubheading Description:: Constructs and returns a @i{condition} of type @i{type} using @i{slot-initializations} for the initial values of the slots. The newly created @i{condition} is returned. @subsubheading Examples:: @example (defvar *oops-count* 0) (setq a (make-condition 'simple-error :format-control "This is your ~:R error." :format-arguments (list (incf *oops-count*)))) @result{} # (format t "~&~A~ @t{ |> } This is your first error. @result{} NIL (error a) @t{ |> } Error: This is your first error. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Return to Lisp Toplevel. @t{ |> } Debug> @end example @subsubheading Affected By:: The set of defined @i{condition} @i{types}. @subsubheading See Also:: @ref{define-condition} , @ref{Condition System Concepts} @node restart, compute-restarts, make-condition, Conditions Dictionary @subsection restart [System Class] @subsubheading Class Precedence List:: @b{restart}, @b{t} @subsubheading Description:: An @i{object} of @i{type} @b{restart} represents a @i{function} that can be called to perform some form of recovery action, usually a transfer of control to an outer point in the running program. An @i{implementation} is free to implement a @i{restart} in whatever manner is most convenient; a @i{restart} has only @i{dynamic extent} relative to the scope of the binding @i{form} which @i{establishes} it. @node compute-restarts, find-restart, restart, Conditions Dictionary @subsection compute-restarts [Function] @code{compute-restarts} @i{{&optional} condition} @result{} @i{restarts} @subsubheading Arguments and Values:: @i{condition}---a @i{condition} @i{object}, or @b{nil}. @i{restarts}---a @i{list} of @i{restarts}. @subsubheading Description:: @b{compute-restarts} uses the dynamic state of the program to compute a @i{list} of the @i{restarts} which are currently active. The resulting @i{list} is ordered so that the innermost (more-recently established) restarts are nearer the head of the @i{list}. When @i{condition} is @i{non-nil}, only those @i{restarts} are considered that are either explicitly associated with that @i{condition}, or not associated with any @i{condition}; that is, the excluded @i{restarts} are those that are associated with a non-empty set of @i{conditions} of which the given @i{condition} is not an @i{element}. If @i{condition} is @b{nil}, all @i{restarts} are considered. @b{compute-restarts} returns all @i{applicable restarts}, including anonymous ones, even if some of them have the same name as others and would therefore not be found by @b{find-restart} when given a @i{symbol} argument. Implementations are permitted, but not required, to return @i{distinct} @i{lists} from repeated calls to @b{compute-restarts} while in the same dynamic environment. The consequences are undefined if the @i{list} returned by @b{compute-restarts} is every modified. @subsubheading Examples:: @example ;; One possible way in which an interactive debugger might present ;; restarts to the user. (defun invoke-a-restart () (let ((restarts (compute-restarts))) (do ((i 0 (+ i 1)) (r restarts (cdr r))) ((null r)) (format t "~&~D: ~A~ (let ((n nil) (k (length restarts))) (loop (when (and (typep n 'integer) (>= n 0) (< n k)) (return t)) (format t "~&Option: ") (setq n (read)) (fresh-line)) (invoke-restart-interactively (nth n restarts))))) (restart-case (invoke-a-restart) (one () 1) (two () 2) (nil () :report "Who knows?" 'anonymous) (one () 'I) (two () 'II)) @t{ |> } 0: ONE @t{ |> } 1: TWO @t{ |> } 2: Who knows? @t{ |> } 3: ONE @t{ |> } 4: TWO @t{ |> } 5: Return to Lisp Toplevel. @t{ |> } Option: @b{|>>}@t{4}@b{<<|} @result{} II ;; Note that in addition to user-defined restart points, COMPUTE-RESTARTS ;; also returns information about any system-supplied restarts, such as ;; the "Return to Lisp Toplevel" restart offered above. @end example @subsubheading Affected By:: Existing restarts. @subsubheading See Also:: @ref{find-restart} , @ref{invoke-restart} , @ref{restart-bind} @node find-restart, invoke-restart, compute-restarts, Conditions Dictionary @subsection find-restart [Function] @code{find-restart} @i{identifier {&optional} condition} {restart} @subsubheading Arguments and Values:: @i{identifier}---a @i{non-nil} @i{symbol}, or a @i{restart}. @i{condition}---a @i{condition} @i{object}, or @b{nil}. @i{restart}---a @i{restart} or @b{nil}. @subsubheading Description:: @b{find-restart} searches for a particular @i{restart} in the current @i{dynamic environment}. When @i{condition} is @i{non-nil}, only those @i{restarts} are considered that are either explicitly associated with that @i{condition}, or not associated with any @i{condition}; that is, the excluded @i{restarts} are those that are associated with a non-empty set of @i{conditions} of which the given @i{condition} is not an @i{element}. If @i{condition} is @b{nil}, all @i{restarts} are considered. If @i{identifier} is a @i{symbol}, then the innermost (most recently established) @i{applicable restart} with that @i{name} is returned. @b{nil} is returned if no such restart is found. If @i{identifier} is a currently active restart, then it is returned. Otherwise, @b{nil} is returned. @subsubheading Examples:: @example (restart-case (let ((r (find-restart 'my-restart))) (format t "~S is named ~S" r (restart-name r))) (my-restart () nil)) @t{ |> } # is named MY-RESTART @result{} NIL (find-restart 'my-restart) @result{} NIL @end example @subsubheading Affected By:: Existing restarts. @b{restart-case}, @b{restart-bind}, @b{with-condition-restarts}. @subsubheading See Also:: @ref{compute-restarts} @subsubheading Notes:: @example (find-restart @i{identifier}) @equiv{} (find @i{identifier} (compute-restarts) :key :restart-name) @end example Although anonymous restarts have a name of @b{nil}, the consequences are unspecified if @b{nil} is given as an @i{identifier}. Occasionally, programmers lament that @b{nil} is not permissible as an @i{identifier} argument. In most such cases, @b{compute-restarts} can probably be used to simulate the desired effect. @node invoke-restart, invoke-restart-interactively, find-restart, Conditions Dictionary @subsection invoke-restart [Function] @code{invoke-restart} @i{restart {&rest} arguments} @result{} @i{@{@i{result}@}{*}} @subsubheading Arguments and Values:: @i{restart}---a @i{restart designator}. @i{argument}---an @i{object}. @i{results}---the @i{values} returned by the @i{function} associated with @i{restart}, if that @i{function} returns. @subsubheading Description:: Calls the @i{function} associated with @i{restart}, passing @i{arguments} to it. @i{Restart} must be valid in the current @i{dynamic environment}. @subsubheading Examples:: @example (defun add3 (x) (check-type x number) (+ x 3)) (foo 'seven) @t{ |> } Error: The value SEVEN was not of type NUMBER. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Specify a different value to use. @t{ |> } 2: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{(invoke-restart 'store-value 7)}@b{<<|} @result{} 10 @end example @subsubheading Side Effects:: A non-local transfer of control might be done by the restart. @subsubheading Affected By:: Existing restarts. @subsubheading Exceptional Situations:: If @i{restart} is not valid, an error of @i{type} @b{control-error} is signaled. @subsubheading See Also:: @ref{find-restart} , @ref{restart-bind} , @ref{restart-case} , @ref{invoke-restart-interactively} @subsubheading Notes:: The most common use for @b{invoke-restart} is in a @i{handler}. It might be used explicitly, or implicitly through @b{invoke-restart-interactively} or a @i{restart function}. @i{Restart functions} call @b{invoke-restart}, not vice versa. That is, @i{invoke-restart} provides primitive functionality, and @i{restart functions} are non-essential ``syntactic sugar.'' @node invoke-restart-interactively, restart-bind, invoke-restart, Conditions Dictionary @subsection invoke-restart-interactively [Function] @code{invoke-restart-interactively} @i{restart} @result{} @i{@{@i{result}@}{*}} @subsubheading Arguments and Values:: @i{restart}---a @i{restart designator}. @i{results}---the @i{values} returned by the @i{function} associated with @i{restart}, if that @i{function} returns. @subsubheading Description:: @b{invoke-restart-interactively} calls the @i{function} associated with @i{restart}, prompting for any necessary arguments. If @i{restart} is a name, it must be valid in the current @i{dynamic environment}. @b{invoke-restart-interactively} prompts for arguments by executing the code provided in the @t{:interactive} keyword to @b{restart-case} or @t{:interactive-function} keyword to @b{restart-bind}. If no such options have been supplied in the corresponding @b{restart-bind} or @b{restart-case}, then the consequences are undefined if the @i{restart} takes required arguments. If the arguments are optional, an argument list of @b{nil} is used. Once the arguments have been determined, @b{invoke-restart-interactively} executes the following: @example (apply #'invoke-restart @i{restart} @i{arguments}) @end example @subsubheading Examples:: @example (defun add3 (x) (check-type x number) (+ x 3)) (add3 'seven) @t{ |> } Error: The value SEVEN was not of type NUMBER. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Specify a different value to use. @t{ |> } 2: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{(invoke-restart-interactively 'store-value)}@b{<<|} @t{ |> } Type a form to evaluate and use: @b{|>>}@t{7}@b{<<|} @result{} 10 @end example @subsubheading Side Effects:: If prompting for arguments is necesary, some typeout may occur (on @i{query I/O}). A non-local transfer of control might be done by the restart. @subsubheading Affected By:: @b{*query-io*}, active @i{restarts} @subsubheading Exceptional Situations:: If @i{restart} is not valid, an error of @i{type} @b{control-error} is signaled. @subsubheading See Also:: @ref{find-restart} , @ref{invoke-restart} , @ref{restart-case} , @ref{restart-bind} @subsubheading Notes:: @b{invoke-restart-interactively} is used internally by the debugger and may also be useful in implementing other portable, interactive debugging tools. @node restart-bind, restart-case, invoke-restart-interactively, Conditions Dictionary @subsection restart-bind [Macro] @code{restart-bind} @i{@r{(}@{{(}name function @{!@i{key-val-pair}@}{*}@r{)}@}{)} @{@i{form}@}{*}}@* @result{} @i{@{@i{result}@}{*}} @w{@i{key-val-pair} ::=@t{:interactive-function} {interactive-function} | } @w{ @t{:report-function} {report-function} | } @w{ @t{:test-function} {test-function}} @subsubheading Arguments and Values:: @i{name}---a @i{symbol}; not evaluated. @i{function}---a @i{form}; evaluated. @i{forms}---an @i{implicit progn}. @i{interactive-function}---a @i{form}; evaluated. @i{report-function}---a @i{form}; evaluated. @i{test-function}---a @i{form}; evaluated. @i{results}---the @i{values} returned by the @i{forms}. @subsubheading Description:: @b{restart-bind} executes the body of @i{forms} in a @i{dynamic environment} where @i{restarts} with the given @i{names} are in effect. If a @i{name} is @b{nil}, it indicates an anonymous restart; if a @i{name} is a @i{non-nil} @i{symbol}, it indicates a named restart. The @i{function}, @i{interactive-function}, and @i{report-function} are unconditionally evaluated in the current lexical and dynamic environment prior to evaluation of the body. Each of these @i{forms} must evaluate to a @i{function}. If @b{invoke-restart} is done on that restart, the @i{function} which resulted from evaluating @i{function} is called, in the @i{dynamic environment} of the @b{invoke-restart}, with the @i{arguments} given to @b{invoke-restart}. The @i{function} may either perform a non-local transfer of control or may return normally. If the restart is invoked interactively from the debugger (using @b{invoke-restart-interactively}), the arguments are defaulted by calling the @i{function} which resulted from evaluating @i{interactive-function}. That @i{function} may optionally prompt interactively on @i{query I/O}, and should return a @i{list} of arguments to be used by @b{invoke-restart-interactively} when invoking the restart. If a restart is invoked interactively but no @i{interactive-function} is used, then an argument list of @b{nil} is used. In that case, the @i{function} must be compatible with an empty argument list. If the restart is presented interactively (@i{e.g.}, by the debugger), the presentation is done by calling the @i{function} which resulted from evaluating @i{report-function}. This @i{function} must be a @i{function} of one argument, a @i{stream}. It is expected to print a description of the action that the restart takes to that @i{stream}. This @i{function} is called any time the restart is printed while @b{*print-escape*} is @b{nil}. In the case of interactive invocation, the result is dependent on the value of @t{:interactive-function} as follows. @table @asis @item @t{:interactive-function} @i{Value} is evaluated in the current lexical environment and should return a @i{function} of no arguments which constructs a @i{list} of arguments to be used by @b{invoke-restart-interactively} when invoking this restart. The @i{function} may prompt interactively using @i{query I/O} if necessary. @item @t{:report-function} @i{Value} is evaluated in the current lexical environment and should return a @i{function} of one argument, a @i{stream}, which prints on the @i{stream} a summary of the action that this restart takes. This @i{function} is called whenever the restart is reported (printed while @b{*print-escape*} is @b{nil}). If no @t{:report-function} option is provided, the manner in which the @i{restart} is reported is @i{implementation-dependent}. @item @t{:test-function} @i{Value} is evaluated in the current lexical environment and should return a @i{function} of one argument, a @i{condition}, which returns @i{true} if the restart is to be considered visible. @end table @subsubheading Affected By:: @b{*query-io*}. @subsubheading See Also:: @ref{restart-case} , @ref{with-simple-restart} @subsubheading Notes:: @b{restart-bind} is primarily intended to be used to implement @b{restart-case} and might be useful in implementing other macros. Programmers who are uncertain about whether to use @b{restart-case} or @b{restart-bind} should prefer @b{restart-case} for the cases where it is powerful enough, using @b{restart-bind} only in cases where its full generality is really needed. @node restart-case, restart-name, restart-bind, Conditions Dictionary @subsection restart-case [Macro] @code{restart-case} @i{restartable-form {@{!@i{clause}@}}} @result{} @i{@{@i{result}@}{*}} @w{@i{clause} ::=@r{(} case-name lambda-list } @w{ [[@t{:interactive} interactive-expression | @t{:report} report-expression | @t{:test} test-expression]] } @w{ @{@i{declaration}@}{*} @{@i{form}@}{*}@r{)}} @subsubheading Arguments and Values:: @i{restartable-form}---a @i{form}. @i{case-name}---a @i{symbol} or @b{nil}. @i{lambda-list}---an @i{ordinary lambda list}. @i{interactive-expression}---a @i{symbol} or a @i{lambda expression}. @i{report-expression}---a @i{string}, a @i{symbol}, or a @i{lambda expression}. @i{test-expression}---a @i{symbol} or a @i{lambda expression}. @i{declaration}---a @b{declare} @i{expression}; not evaluated. @i{form}---a @i{form}. @i{results}---the @i{values} resulting from the @i{evaluation} of @i{restartable-form}, or the @i{values} returned by the last @i{form} executed in a chosen @i{clause}, or @b{nil}. @subsubheading Description:: @b{restart-case} evaluates @i{restartable-form} in a @i{dynamic environment} where the clauses have special meanings as points to which control may be transferred. If @i{restartable-form} finishes executing and returns any values, all values returned are returned by @b{restart-case} and processing has completed. While @i{restartable-form} is executing, any code may transfer control to one of the clauses (see @b{invoke-restart}). If a transfer occurs, the forms in the body of that clause is evaluated and any values returned by the last such form are returned by @b{restart-case}. In this case, the dynamic state is unwound appropriately (so that the restarts established around the @i{restartable-form} are no longer active) prior to execution of the clause. If there are no @i{forms} in a selected clause, @b{restart-case} returns @b{nil}. If @i{case-name} is a @i{symbol}, it names this restart. It is possible to have more than one clause use the same @i{case-name}. In this case, the first clause with that name is found by @b{find-restart}. The other clauses are accessible using @b{compute-restarts}. Each @i{arglist} is an @i{ordinary lambda list} to be bound during the execution of its corresponding @i{forms}. These parameters are used by the @b{restart-case} clause to receive any necessary data from a call to @b{invoke-restart}. By default, @b{invoke-restart-interactively} passes no arguments and all arguments must be optional in order to accomodate interactive restarting. However, the arguments need not be optional if the @t{:interactive} keyword has been used to inform @b{invoke-restart-interactively} about how to compute a proper argument list. @i{Keyword} options have the following meaning. @table @asis @item @t{:interactive} The @i{value} supplied by @t{:interactive @i{value}} must be a suitable argument to @b{function}. @t{(function @i{value})} is evaluated in the current lexical environment. It should return a @i{function} of no arguments which returns arguments to be used by @b{invoke-restart-interactively} when it is invoked. @b{invoke-restart-interactively} is called in the dynamic environment available prior to any restart attempt, and uses @i{query I/O} for user interaction. If a restart is invoked interactively but no @t{:interactive} option was supplied, the argument list used in the invocation is the empty list. @item @t{:report} If the @i{value} supplied by @t{:report @i{value}} is a @i{lambda expression} or a @i{symbol}, it must be acceptable to @b{function}. @t{(function @i{value})} is evaluated in the current lexical environment. It should return a @i{function} of one argument, a @i{stream}, which prints on the @i{stream} a description of the restart. This @i{function} is called whenever the restart is printed while @b{*print-escape*} is @b{nil}. If @i{value} is a @i{string}, it is a shorthand for @example (lambda (stream) (write-string value stream)) @end example If a named restart is asked to report but no report information has been supplied, the name of the restart is used in generating default report text. When @b{*print-escape*} is @b{nil}, the printer uses the report information for a restart. For example, a debugger might announce the action of typing a ``continue'' command by: @example (format t "~&~S -- ~A~ @end example which might then display as something like: @example :CONTINUE -- Return to command level @end example The consequences are unspecified if an unnamed restart is specified but no @t{:report} option is provided. @item @t{:test} The @i{value} supplied by @t{:test @i{value}} must be a suitable argument to @b{function}. @t{(function @i{value})} is evaluated in the current lexical environment. It should return a @i{function} of one @i{argument}, the @i{condition}, that returns @i{true} if the restart is to be considered visible. The default for this option is equivalent to @t{(lambda (c) (declare (ignore c)) t)}. @end table If the @i{restartable-form} is a @i{list} whose @i{car} is any of the @i{symbols} @b{signal}, @b{error}, @b{cerror}, or @b{warn} (or is a @i{macro form} which macroexpands into such a @i{list}), then @b{with-condition-restarts} is used implicitly to associate the indicated @i{restarts} with the @i{condition} to be signaled. @subsubheading Examples:: @example (restart-case (handler-bind ((error #'(lambda (c) (declare (ignore condition)) (invoke-restart 'my-restart 7)))) (error "Foo.")) (my-restart (&optional v) v)) @result{} 7 (define-condition food-error (error) ()) @result{} FOOD-ERROR (define-condition bad-tasting-sundae (food-error) ((ice-cream :initarg :ice-cream :reader bad-tasting-sundae-ice-cream) (sauce :initarg :sauce :reader bad-tasting-sundae-sauce) (topping :initarg :topping :reader bad-tasting-sundae-topping)) (:report (lambda (condition stream) (format stream "Bad tasting sundae with ~S, ~S, and ~S" (bad-tasting-sundae-ice-cream condition) (bad-tasting-sundae-sauce condition) (bad-tasting-sundae-topping condition))))) @result{} BAD-TASTING-SUNDAE (defun all-start-with-same-letter (symbol1 symbol2 symbol3) (let ((first-letter (char (symbol-name symbol1) 0))) (and (eql first-letter (char (symbol-name symbol2) 0)) (eql first-letter (char (symbol-name symbol3) 0))))) @result{} ALL-START-WITH-SAME-LETTER (defun read-new-value () (format t "Enter a new value: ") (multiple-value-list (eval (read)))) @result{} READ-NEW-VALUE@page (defun verify-or-fix-perfect-sundae (ice-cream sauce topping) (do () ((all-start-with-same-letter ice-cream sauce topping)) (restart-case (error 'bad-tasting-sundae :ice-cream ice-cream :sauce sauce :topping topping) (use-new-ice-cream (new-ice-cream) :report "Use a new ice cream." :interactive read-new-value (setq ice-cream new-ice-cream)) (use-new-sauce (new-sauce) :report "Use a new sauce." :interactive read-new-value (setq sauce new-sauce)) (use-new-topping (new-topping) :report "Use a new topping." :interactive read-new-value (setq topping new-topping)))) (values ice-cream sauce topping)) @result{} VERIFY-OR-FIX-PERFECT-SUNDAE (verify-or-fix-perfect-sundae 'vanilla 'caramel 'cherry) @t{ |> } Error: Bad tasting sundae with VANILLA, CARAMEL, and CHERRY. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Use a new ice cream. @t{ |> } 2: Use a new sauce. @t{ |> } 3: Use a new topping. @t{ |> } 4: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @t{ |> } Use a new ice cream. @t{ |> } Enter a new ice cream: @b{|>>}@t{'chocolate}@b{<<|} @result{} CHOCOLATE, CARAMEL, CHERRY @end example @subsubheading See Also:: @ref{restart-bind} , @ref{with-simple-restart} . @subsubheading Notes:: @example (restart-case @i{expression} (@i{name1} @i{arglist1} ...@i{options1}... . @i{body1}) (@i{name2} @i{arglist2} ...@i{options2}... . @i{body2})) @end example is essentially equivalent to @example (block #1=#:g0001 (let ((#2=#:g0002 nil)) (tagbody (restart-bind ((name1 #'(lambda (&rest temp) (setq #2# temp) (go #3=#:g0003)) ...@i{slightly-transformed-options1}...) (name2 #'(lambda (&rest temp) (setq #2# temp) (go #4=#:g0004)) ...@i{slightly-transformed-options2}...)) (return-from #1# @i{expression})) #3# (return-from #1# (apply #'(lambda @i{arglist1} . @i{body1}) #2#)) #4# (return-from #1# (apply #'(lambda @i{arglist2} . @i{body2}) #2#))))) @end example Unnamed restarts are generally only useful interactively and an interactive option which has no description is of little value. Implementations are encouraged to warn if an unnamed restart is used and no report information is provided at compilation time. At runtime, this error might be noticed when entering the debugger. Since signaling an error would probably cause recursive entry into the debugger (causing yet another recursive error, etc.) it is suggested that the debugger print some indication of such problems when they occur but not actually signal errors. @example (restart-case (signal fred) (a ...) (b ...)) @equiv{} (restart-case (with-condition-restarts fred (list (find-restart 'a) (find-restart 'b)) (signal fred)) (a ...) (b ...)) @end example @node restart-name, with-condition-restarts, restart-case, Conditions Dictionary @subsection restart-name [Function] @code{restart-name} @i{restart} @result{} @i{name} @subsubheading Arguments and Values:: @i{restart}---a @i{restart}. @i{name}---a @i{symbol}. @subsubheading Description:: Returns the name of the @i{restart}, or @b{nil} if the @i{restart} is not named. @subsubheading Examples:: @example (restart-case (loop for restart in (compute-restarts) collect (restart-name restart)) (case1 () :report "Return 1." 1) (nil () :report "Return 2." 2) (case3 () :report "Return 3." 3) (case1 () :report "Return 4." 4)) @result{} (CASE1 NIL CASE3 CASE1 ABORT) ;; In the example above the restart named ABORT was not created ;; explicitly, but was implicitly supplied by the system. @end example @subsubheading See Also:: @ref{compute-restarts} @ref{find-restart} @node with-condition-restarts, with-simple-restart, restart-name, Conditions Dictionary @subsection with-condition-restarts [Macro] @code{with-condition-restarts} @i{condition-form restarts-form @{@i{form}@}{*}}@* @result{} @i{@{@i{result}@}{*}} @subsubheading Arguments and Values:: @i{condition-form}---a @i{form}; @i{evaluated} to produce a @i{condition}. @i{condition}---a @i{condition} @i{object} resulting from the @i{evaluation} of @i{condition-form}. @i{restart-form}---a @i{form}; @i{evaluated} to produce a @i{restart-list}. @i{restart-list}---a @i{list} of @i{restart} @i{objects} resulting from the @i{evaluation} of @i{restart-form}. @i{forms}---an @i{implicit progn}; evaluated. @i{results}---the @i{values} returned by @i{forms}. @subsubheading Description:: First, the @i{condition-form} and @i{restarts-form} are @i{evaluated} in normal left-to-right order; the @i{primary values} yielded by these @i{evaluations} are respectively called the @i{condition} and the @i{restart-list}. Next, the @i{forms} are @i{evaluated} in a @i{dynamic environment} in which each @i{restart} in @i{restart-list} is associated with the @i{condition}. See @ref{Associating a Restart with a Condition}. @subsubheading See Also:: @ref{restart-case} @subsubheading Notes:: Usually this @i{macro} is not used explicitly in code, since @b{restart-case} handles most of the common cases in a way that is syntactically more concise. @node with-simple-restart, abort, with-condition-restarts, Conditions Dictionary @subsection with-simple-restart [Macro] @code{with-simple-restart} @i{@r{(}name format-control @{@i{format-argument}@}{*}@r{)} @{@i{form}@}{*}}@* @result{} @i{@{@i{result}@}{*}} @subsubheading Arguments and Values:: @i{name}---a @i{symbol}. @i{format-control}---a @i{format control}. @i{format-argument}---an @i{object} (@i{i.e.}, a @i{format argument}). @i{forms}---an @i{implicit progn}. @i{results}---in the normal situation, the @i{values} returned by the @i{forms}; in the exceptional situation where the @i{restart} named @i{name} is invoked, two values---@b{nil} and @b{t}. @subsubheading Description:: @b{with-simple-restart} establishes a restart. If the restart designated by @i{name} is not invoked while executing @i{forms}, all values returned by the last of @i{forms} are returned. If the restart designated by @i{name} is invoked, control is transferred to @b{with-simple-restart}, which returns two values, @b{nil} and @b{t}. If @i{name} is @b{nil}, an anonymous restart is established. The @i{format-control} and @i{format-arguments} are used report the @i{restart}. @subsubheading Examples:: @example (defun read-eval-print-loop (level) (with-simple-restart (abort "Exit command level ~D." level) (loop (with-simple-restart (abort "Return to command level ~D." level) (let ((form (prog2 (fresh-line) (read) (fresh-line)))) (prin1 (eval form))))))) @result{} READ-EVAL-PRINT-LOOP (read-eval-print-loop 1) (+ 'a 3) @t{ |> } Error: The argument, A, to the function + was of the wrong type. @t{ |> } The function expected a number. @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Specify a value to use this time. @t{ |> } 2: Return to command level 1. @t{ |> } 3: Exit command level 1. @t{ |> } 4: Return to Lisp Toplevel. @end example @example (defun compute-fixnum-power-of-2 (x) (with-simple-restart (nil "Give up on computing 2{@t{^}}~D." x) (let ((result 1)) (dotimes (i x result) (setq result (* 2 result)) (unless (fixnump result) (error "Power of 2 is too large.")))))) COMPUTE-FIXNUM-POWER-OF-2 (defun compute-power-of-2 (x) (or (compute-fixnum-power-of-2 x) 'something big)) COMPUTE-POWER-OF-2 (compute-power-of-2 10) 1024 (compute-power-of-2 10000) @t{ |> } Error: Power of 2 is too large. @t{ |> } To continue, type :CONTINUE followed by an option number. @t{ |> } 1: Give up on computing 2{@t{^}}10000. @t{ |> } 2: Return to Lisp Toplevel @t{ |> } Debug> @b{|>>}@t{:continue 1}@b{<<|} @result{} SOMETHING-BIG @end example @subsubheading See Also:: @ref{restart-case} @subsubheading Notes:: @b{with-simple-restart} is shorthand for one of the most common uses of @b{restart-case}. @b{with-simple-restart} could be defined by: @example (defmacro with-simple-restart ((restart-name format-control &rest format-arguments) &body forms) `(restart-case (progn ,@@forms) (,restart-name () :report (lambda (stream) (format stream ,format-control ,@@format-arguments)) (values nil t)))) @end example Because the second return value is @b{t} in the exceptional case, it is common (but not required) to arrange for the second return value in the normal case to be missing or @b{nil} so that the two situations can be distinguished. @node abort, continue, with-simple-restart, Conditions Dictionary @subsection abort [Restart] @subsubheading Data Arguments Required:: None. @subsubheading Description:: The intent of the @b{abort} restart is to allow return to the innermost ``command level.'' Implementors are encouraged to make sure that there is always a restart named @b{abort} around any user code so that user code can call @b{abort} at any time and expect something reasonable to happen; exactly what the reasonable thing is may vary somewhat. Typically, in an interactive listener, the invocation of @b{abort} returns to the @i{Lisp reader} phase of the @i{Lisp read-eval-print loop}, though in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate. @subsubheading See Also:: @ref{Restarts}, @ref{Interfaces to Restarts}, @ref{invoke-restart} , @ref{abort} (@i{function}) @node continue, muffle-warning, abort, Conditions Dictionary @subsection continue [Restart] @subsubheading Data Arguments Required:: None. @subsubheading Description:: The @b{continue} @i{restart} is generally part of protocols where there is a single ``obvious'' way to continue, such as in @b{break} and @b{cerror}. Some user-defined protocols may also wish to incorporate it for similar reasons. In general, however, it is more reliable to design a special purpose restart with a name that more directly suits the particular application. @subsubheading Examples:: @example (let ((x 3)) (handler-bind ((error #'(lambda (c) (let ((r (find-restart 'continue c))) (when r (invoke-restart r)))))) (cond ((not (floatp x)) (cerror "Try floating it." "~D is not a float." x) (float x)) (t x)))) @result{} 3.0 @end example @subsubheading See Also:: @ref{Restarts}, @ref{Interfaces to Restarts}, @ref{invoke-restart} , @ref{continue} (@i{function}), @ref{assert} , @ref{cerror} @node muffle-warning, store-value, continue, Conditions Dictionary @subsection muffle-warning [Restart] @subsubheading Data Arguments Required:: None. @subsubheading Description:: This @i{restart} is established by @b{warn} so that @i{handlers} of @b{warning} @i{conditions} have a way to tell @b{warn} that a warning has already been dealt with and that no further action is warranted. @subsubheading Examples:: @example (defvar *all-quiet* nil) @result{} *ALL-QUIET* (defvar *saved-warnings* '()) @result{} *SAVED-WARNINGS* (defun quiet-warning-handler (c) (when *all-quiet* (let ((r (find-restart 'muffle-warning c))) (when r (push c *saved-warnings*) (invoke-restart r))))) @result{} CUSTOM-WARNING-HANDLER (defmacro with-quiet-warnings (&body forms) `(let ((*all-quiet* t) (*saved-warnings* '())) (handler-bind ((warning #'quiet-warning-handler)) ,@@forms *saved-warnings*))) @result{} WITH-QUIET-WARNINGS (setq saved (with-quiet-warnings (warn "Situation #1.") (let ((*all-quiet* nil)) (warn "Situation #2.")) (warn "Situation #3."))) @t{ |> } Warning: Situation #2. @result{} (# #) (dolist (s saved) (format t "~&~A~ @t{ |> } Situation #3. @t{ |> } Situation #1. @result{} NIL @end example @subsubheading See Also:: @ref{Restarts}, @ref{Interfaces to Restarts}, @ref{invoke-restart} , @ref{muffle-warning} (@i{function}), @ref{warn} @node store-value, use-value, muffle-warning, Conditions Dictionary @subsection store-value [Restart] @subsubheading Data Arguments Required:: a value to use instead (on an ongoing basis). @subsubheading Description:: The @b{store-value} @i{restart} is generally used by @i{handlers} trying to recover from errors of @i{types} such as @b{cell-error} or @b{type-error}, which may wish to supply a replacement datum to be stored permanently. @subsubheading Examples:: @example (defun type-error-auto-coerce (c) (when (typep c 'type-error) (let ((r (find-restart 'store-value c))) (handler-case (let ((v (coerce (type-error-datum c) (type-error-expected-type c)))) (invoke-restart r v)) (error ()))))) @result{} TYPE-ERROR-AUTO-COERCE (let ((x 3)) (handler-bind ((type-error #'type-error-auto-coerce)) (check-type x float) x)) @result{} 3.0 @end example @subsubheading See Also:: @ref{Restarts}, @ref{Interfaces to Restarts}, @ref{invoke-restart} , @ref{store-value} (@i{function}), @b{ccase}, @ref{check-type} , @b{ctypecase}, @ref{use-value} (@i{function} and @i{restart}) @node use-value, abort, store-value, Conditions Dictionary @subsection use-value [Restart] @subsubheading Data Arguments Required:: a value to use instead (once). @subsubheading Description:: The @b{use-value} @i{restart} is generally used by @i{handlers} trying to recover from errors of @i{types} such as @b{cell-error}, where the handler may wish to supply a replacement datum for one-time use. @subsubheading See Also:: @ref{Restarts}, @ref{Interfaces to Restarts}, @ref{invoke-restart} , @ref{use-value} (@i{function}), @ref{store-value} (@i{function} and @i{restart}) @node abort, , use-value, Conditions Dictionary @subsection abort, continue, muffle-warning, store-value, use-value [Function] @IRindex{abort} @IRindex{continue} @IRindex{muffle-warning} @IRindex{store-value} @IRindex{use-value} @code{abort} @i{{&optional} condition} @result{} # @code{continue} @i{{&optional} condition} @result{} @i{@b{nil}} @code{muffle-warning} @i{{&optional} condition} @result{} # @code{store-value} @i{value {&optional} condition} @result{} @i{@b{nil}} @code{use-value} @i{value {&optional} condition} @result{} @i{@b{nil}} @subsubheading Arguments and Values:: @i{value}---an @i{object}. @i{condition}---a @i{condition} @i{object}, or @b{nil}. @subsubheading Description:: Transfers control to the most recently established @i{applicable restart} having the same name as the function. That is, the @i{function} @b{abort} searches for an @i{applicable} @b{abort} @i{restart}, the @i{function} @b{continue} searches for an @i{applicable} @b{continue} @i{restart}, and so on. If no such @i{restart} exists, the functions @b{continue}, @b{store-value}, and @b{use-value} return @b{nil}, and the functions @b{abort} and @b{muffle-warning} signal an error of @i{type} @b{control-error}. When @i{condition} is @i{non-nil}, only those @i{restarts} are considered that are either explicitly associated with that @i{condition}, or not associated with any @i{condition}; that is, the excluded @i{restarts} are those that are associated with a non-empty set of @i{conditions} of which the given @i{condition} is not an @i{element}. If @i{condition} is @b{nil}, all @i{restarts} are considered. @subsubheading Examples:: @example ;;; Example of the ABORT retart (defmacro abort-on-error (&body forms) `(handler-bind ((error #'abort)) ,@@forms)) @result{} ABORT-ON-ERROR (abort-on-error (+ 3 5)) @result{} 8 (abort-on-error (error "You lose.")) @t{ |> } Returned to Lisp Top Level. ;;; Example of the CONTINUE restart (defun real-sqrt (n) (when (minusp n) (setq n (- n)) (cerror "Return sqrt(~D) instead." "Tried to take sqrt(-~D)." n)) (sqrt n)) (real-sqrt 4) @result{} 2 (real-sqrt -9) @t{ |> } Error: Tried to take sqrt(-9). @t{ |> } To continue, type :CONTINUE followed by an option number: @t{ |> } 1: Return sqrt(9) instead. @t{ |> } 2: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{(continue)}@b{<<|} @t{ |> } Return sqrt(9) instead. @result{} 3 (handler-bind ((error #'(lambda (c) (continue)))) (real-sqrt -9)) @result{} 3 ;;; Example of the MUFFLE-WARNING restart (defun count-down (x) (do ((counter x (1- counter))) ((= counter 0) 'done) (when (= counter 1) (warn "Almost done")) (format t "~&~D~ @result{} COUNT-DOWN (count-down 3) @t{ |> } 3 @t{ |> } 2 @t{ |> } Warning: Almost done @t{ |> } 1 @result{} DONE (defun ignore-warnings-while-counting (x) (handler-bind ((warning #'ignore-warning)) (count-down x))) @result{} IGNORE-WARNINGS-WHILE-COUNTING (defun ignore-warning (condition) (declare (ignore condition)) (muffle-warning)) @result{} IGNORE-WARNING (ignore-warnings-while-counting 3) @t{ |> } 3 @t{ |> } 2 @t{ |> } 1 @result{} DONE ;;; Example of the STORE-VALUE and USE-VALUE restarts (defun careful-symbol-value (symbol) (check-type symbol symbol) (restart-case (if (boundp symbol) (return-from careful-symbol-value (symbol-value symbol)) (error 'unbound-variable :name symbol)) (use-value (value) :report "Specify a value to use this time." value) (store-value (value) :report "Specify a value to store and use in the future." (setf (symbol-value symbol) value)))) (setq a 1234) @result{} 1234 (careful-symbol-value 'a) @result{} 1234 (makunbound 'a) @result{} A (careful-symbol-value 'a) @t{ |> } Error: A is not bound. @t{ |> } To continue, type :CONTINUE followed by an option number. @t{ |> } 1: Specify a value to use this time. @t{ |> } 2: Specify a value to store and use in the future. @t{ |> } 3: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{(use-value 12)}@b{<<|} @result{} 12 (careful-symbol-value 'a) @t{ |> } Error: A is not bound. @t{ |> } To continue, type :CONTINUE followed by an option number. @t{ |> } 1: Specify a value to use this time. @t{ |> } 2: Specify a value to store and use in the future. @t{ |> } 3: Return to Lisp Toplevel. @t{ |> } Debug> @b{|>>}@t{(store-value 24)}@b{<<|} @result{} 24 (careful-symbol-value 'a) @result{} 24 ;;; Example of the USE-VALUE restart (defun add-symbols-with-default (default &rest symbols) (handler-bind ((sys:unbound-symbol #'(lambda (c) (declare (ignore c)) (use-value default)))) (apply #'+ (mapcar #'careful-symbol-value symbols)))) @result{} ADD-SYMBOLS-WITH-DEFAULT (setq x 1 y 2) @result{} 2 (add-symbols-with-default 3 'x 'y 'z) @result{} 6 @end example @subsubheading Side Effects:: A transfer of control may occur if an appropriate @i{restart} is available, or (in the case of the @i{function} @b{abort} or the @i{function} @b{muffle-warning}) execution may be stopped. @subsubheading Affected By:: Each of these functions can be affected by the presence of a @i{restart} having the same name. @subsubheading Exceptional Situations:: If an appropriate @b{abort} @i{restart} is not available for the @i{function} @b{abort}, or an appropriate @b{muffle-warning} @i{restart} is not available for the @i{function} @b{muffle-warning}, an error of @i{type} @b{control-error} is signaled. @subsubheading See Also:: @ref{invoke-restart} , @ref{Restarts}, @ref{Interfaces to Restarts}, @ref{assert} , @b{ccase}, @ref{cerror} , @ref{check-type} , @b{ctypecase}, @ref{use-value} , @ref{warn} @subsubheading Notes:: @example (abort condition) @equiv{} (invoke-restart 'abort) (muffle-warning) @equiv{} (invoke-restart 'muffle-warning) (continue) @equiv{} (let ((r (find-restart 'continue))) (if r (invoke-restart r))) (use-value @i{x}) @equiv{} (let ((r (find-restart 'use-value))) (if r (invoke-restart r @i{x}))) (store-value x) @equiv{} (let ((r (find-restart 'store-value))) (if r (invoke-restart r @i{x}))) @end example No functions defined in this specification are required to provide a @b{use-value} @i{restart}. @c end of including dict-conditions @c %**end of chapter