condition.tex

%%%Chapter of Common Lisp Manual.  Copyright 1989 Guy L. Steele Jr.
\clearpage\def\pagestatus{FINAL PROOF}

\def\SU#1{${}_{#1}$}

\ifx \rulang\Undef

\chapter{Conditions}
\label{CONDITION}


Author: Kent M. Pitman

This chapter presents the bulk of the Common Lisp
Condition System proposal, written by Kent~M. Pitman
and amended by X3J13.  I have edited it only very lightly
to conform to the overall style of this book and have inserted a small
number of bracketed remarks identified by the initials GLS.
Please see the Acknowledgments to this second edition for the author's
acknowledgments to others who contributed to the Condition System proposal.

\noindent\hbox to \textwidth{\hss---Guy L. Steele Jr.}

\section{Introduction}

Often we find it useful to describe a function in terms of its behavior in
``normal situations.'' For example, we may say informally that the function
\cdf{+} returns the sum of its arguments or that the function
\cdf{read-char} returns the next available character on a given input
stream.

Sometimes, however, an ``exceptional situation'' will arise that does not fit
neatly into such descriptions. For example, \cdf{+} might receive an argument
that is not a number, or \cdf{read-char} might receive as a single argument
a stream that has no more available characters.  This distinction between normal
and exceptional situations is in some sense arbitrary but is often very
useful in practice.

For example, suppose a function \cdf{f} were defined to allow only
integer arguments but also guaranteed to
detect and signal an error for non-integer arguments.
Such a description is in fact internally inconsistent (that is,
paradoxical) because the function's behavior is well-defined for non-integers.
Yet we would not want this annoying paradox to force description of \cdf{f}
as a function that accepts any kind of argument (just in case \cdf{f}
is being called only as a quick way to signal an error, for example).
Using the normal/exceptional distinction, we can say clearly that \cdf{f} accepts integers
in the normal situation and signals an error in exceptional situations.
Moreover, we can say that when we refer to the definition of a
function informally, it is acceptable to speak only of its normal behavior.
For example, we can speak informally about \cdf{f} as a function that accepts only
integers without feeling that we are committing some awful fraud.

Not all exceptional situations are errors.  For example, a program that is
directing the typing of a long line of text may come to an end-of-line.
It is possible that no real harm will result from failing to signal end-of-line
to its caller because the operating system will simply force a carriage
return on the output device, which will continue typing on the next line. However, it
may still be interesting to establish a protocol whereby the printing program can
inform its caller of end-of-line exceptions. The caller could
then opt to deal with these situations in interesting ways at certain times.
For example, a caller might choose to terminate printing, obtaining an end-of-line
truncation. The important thing, however, is that the failure of the
caller to provide advice about the situation need not prevent
the printer program from operating correctly.

Mechanisms for dealing with exceptional situations vary widely. When an
exceptional situation is encountered, a program may attempt to handle
it by returning a distinguished value, returning an additional value,
setting a variable, calling a function, performing a special transfer of
control, or stopping the program altogether and entering the debugger.

For the most part, the facilities described in this chapter do not introduce
any fundamentally new way of dealing with exceptional situations. Rather, they
encapsulate and formalize useful patterns of data and control flow that have
been seen to be useful in dealing with exceptional situations.

A proper conceptual approach to errors should perhaps begin from first
principles, with a discussion of \emph{conditions} in general, and eventually work
up to the concept of an \emph{error} as just one of the many kinds of
conditions. However, given the primitive state of error-handling
technology, a proper buildup may be as inappropriate as requiring that a
beggar learn to cook a gourmet meal before being allowed to eat.  Thus,
we deal first with the essentials---error handling---and then
go back later to fill in the missing details.

\section{Changes in Terminology}

In this section, we introduce changes to the terminology
defined in section~\ref{INTRO-ERRORS}.

A \emph{condition} is an interesting situation in a program that has been
detected and announced. Later we allow this term also to refer to
objects that programs use to represent such situations.

An \emph{error} is a condition in which normal program execution may not
continue without some form of intervention (either interactively by 
the user
or under some sort of program control, as described below).

The process by which a condition is formally announced by a program is called
\emph{signaling}. The function \cdf{signal} is the primitive mechanism by which such
announcement is done. Other abstractions, such as \cdf{error} and \cdf{cerror}, are built
using \cdf{signal}.

The first edition is ambiguous about the reason why a particular program action
``is an error.'' There are two principal reasons why an action may be an error
without being required to signal an error:
\begin{itemize}
\item Detecting the error might be prohibitively expensive.

   For example, \cd{(+ nil 3)} is an error. It is likely that the designers of
   Common Lisp believed this would be an error in all implementations but
   felt it might be excessively expensive to detect the problem
   in compiled code on stock hardware, so they did not require that it signal
   an error.

\item Some implementations might implement the behavior as an extension.

   For example, \cd{(loop for x from 1 to 3 do (print x))} is an error because \cdf{loop}
   is not defined to take atoms in its body.
   In fact, however, some
   implementations offer an extension that makes this well-defined. In order
   to leave room for such extensions, the first edition used the ``is an error''
   terminology to keep implementors from being forced to signal an error in
   the extended implementations.

   [This example was written well before the vote by X3J13 in January 1989
    to add exactly this extension to the forthcoming draft standard
    (see chapter~\ref{LOOP}).---GLS]
\end{itemize}

In this chapter, we use the following terminology.
[Compare this to the terminology presented
in section~\ref{Error-Terminology-SECTION}.---GLS]
\begin{itemize}
\item
   If the signaling of a condition or error is part of a function's contract
   in all situations, we say that it ``signals'' or ``must signal'' that
   condition or error.

\item
   If the signaling of a condition or error is optional for some important
   reason (such as performance), we say that the program ``might signal''
   that condition or error. In this case, we are defining the operation to be
   illegal in all implementations, but allowing some implementations to fail to
   detect the error.

\item
   If an action is left undefined for the sake of implementation-dependent
   extension, we say that it ``is undefined'' or ``has undefined effect.''
   This means that it is not possible to depend portably upon the effects of
   that action. A program that has undefined effect may enter the debugger,
   transfer control, or modify data in unpredictable ways.

\item
   In the special case where only the return value of an operation is not
   well defined but any side effect and transfer-of-control behavior is
   well defined, we say that it has ``undefined value.'' In this case,
   the number and nature of the return values is not defined, but the
   function can reasonably be expected to return. It is worth noting that
   under this description, there are some (though not many) legitimate ways
   in which such return value(s) can be used. For example, if the function
   \cdf{foo} has no side effects and undefined value, the expression 
   \cd{(length (list (foo)))} is completely well defined even for portable code.
   However, the effect of \cd{(print (list (foo)))} is not well defined.
\end{itemize}


\section{Survey of Concepts}

This section discusses various aspects of the condition system by topic,
illustrating them with extensive examples.  The next section contains
definitions of specific functions, macros, and other facilities.

\subsection{Signaling Errors}

Conceptually, signaling an error in a program is an admission by that program
that it does not know how to continue and requires external intervention. Once
an error is signaled, any decision about how to continue must come from the
``outside.''

The simplest way to signal an error is to use the \cdf{error} function with
\cdf{format}-style arguments describing the error for the sake of the user interface.
If \cdf{error} is called and there are no active handlers (described
in sections~\ref{TRAPPING-ERRORS} and~\ref{HANDLING-CONDITIONS}), the
debugger will be entered and the error message will be typed out. For example:
\begin{lisp}
Lisp> (defun factorial (x) \\*
~~~~~~~~(cond ((or (not (typep x 'integer)) (minusp x)) \\*
~~~~~~~~~~~~~~~(error "{\Xtilde}S is not a valid argument to FACTORIAL." \\*
~~~~~~~~~~~~~~~~~~~~~~x)) \\
~~~~~~~~~~~~~~((zerop x) 1) \\
~~~~~~~~~~~~~~(t (* x (factorial (- x 1)))))) \\*
~\EV\ FACTORIAL \\
Lisp> (factorial 20) \\*
~\EV\ 2432902008176640000 \\
Lisp> (factorial -1) \\*
Error: -1 is not a valid argument to FACTORIAL. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Return to Lisp Toplevel. \\*
Debug> 
\end{lisp}
In general, a call to \cdf{error} cannot directly return. Unless special work has
been done to override this behavior, the debugger will be entered and there
will be no option to simply continue.

The only exception may be that some implementations may provide debugger
commands for interactively returning from individual stack frames; even then,
however, such commands should never be used except by someone who has read the
erring code and understands the consequences of continuing from that point. In
particular, the programmer should feel confident
about writing code like this:
\begin{lisp}
(defun wargames:no-win-scenario () \\*
~~(when (true) (error "Pushing the button would be stupid.")) \\*
~~(push-the-button))
\end{lisp}
In this scenario, there should be no chance that the function \cdf{error} will return
and the button will be pushed.

\beforenoterule
\begin{sideremark}
It should be noted that the notion of
``no chance'' that the button will be pushed is relative only to the language
model; it assumes that the language is accurately implemented.  In practice,
compilers have bugs, computers have glitches, and users have been known
to interrupt at inopportune moments and use the debugger to return from
arbitrary stack frames.  Such violations of the language model are
beyond the scope of the condition system but not necessarily beyond the
scope of potential failures that the programmer should consider and defend against.
The possibility of such unusual failures may of course also influence the design of
code meant to handle less drastic situations,
such as maintaining a database uncorrupted.---KMP and GLS
\end{sideremark}
\afternoterule

In some cases, the programmer may have a single, well-defined idea of a
reasonable recovery strategy for this particular error. In that case, he can
use the function \cdf{cerror}, which specifies information about what would happen
if the user did simply continue from the call to \cdf{cerror}. For example:
\begin{lisp}
Lisp> (defun factorial (x) \\*
~~~~~~~~(cond ((not (typep x 'integer)) \\*
~~~~~~~~~~~~~~~(error "{\Xtilde}S is not a valid argument to FACTORIAL." \\*
~~~~~~~~~~~~~~~~~~~~~~x)) \\
~~~~~~~~~~~~~~((minusp x) \\*
~~~~~~~~~~~~~~~(let ((x-magnitude (- x))) \\*
~~~~~~~~~~~~~~~~~(cerror "Compute -({\Xtilde}D!) instead." \\*
~~~~~~~~~~~~~~~~~~~~~~~~~"(-{\Xtilde}D)! is not defined." x-magnitude) \\*
~~~~~~~~~~~~~~~~~(- (factorial x-magnitude)))) \\
~~~~~~~~~~~~~~((zerop x) 1) \\
~~~~~~~~~~~~~~(t (* x (factorial (- x 1)))))) \\*
~\EV\ FACTORIAL \\
Lisp> (factorial -3) \\*
Error: (-3)! is not defined. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Compute -(3!) instead. \\*
~2: Return to Lisp Toplevel. \\*
Debug> :continue 1 \\
~\EV\ -6
\end{lisp}

\subsection{Trapping Errors}
\label{TRAPPING-ERRORS}

By default, a call to \cdf{error} will force entry into the debugger.  You can
override that behavior in a variety of ways. The simplest (and most blunt)
tool for inhibiting entry to the debugger on an error is to use \cdf{ignore-errors}.
In the normal situation, forms in the body of \cdf{ignore-errors} are evaluated
sequentially and the last value is returned. If a condition of type \cdf{error} is
signaled, \cdf{ignore-errors} immediately returns two values, namely \cdf{nil} and the
condition that was signaled; the debugger is not entered and no error
message is printed. For example:
\begin{lisp}
Lisp> (setq filename "nosuchfile") \\
~\EV\ "nosuchfile" \\
Lisp> (ignore-errors (open filename :direction :input)) \\
~\EV\ NIL \textrm{and} \#<FILE-ERROR 3437523>
\end{lisp}
The second return value is an object that represents the kind of error. This
is explained in greater detail in section~\ref{OBJECT-0RIENTED-BASIS}.

In many cases, however, \cdf{ignore-errors} is not desirable because it deals with
too many kinds of errors. Contrary to the belief of some, a program that
does not enter the debugger is not necessarily better than one that does.
Excessive use of \cdf{ignore-errors} may keep the program out of the debugger, but it may
not increase the program's reliability, because the program may continue
to run after encountering errors other than those you meant to work past. In
general, it is better to attempt to deal only with the particular kinds of
errors that you believe could legitimately happen. That way, if an unexpected
error comes along, you will still find out about it.

\cdf{ignore-errors} is a useful special case built from a more general facility,
\cdf{handler-case}, that allows the programmer to deal with particular kinds of
conditions (including non-error conditions) without affecting what happens
when other kinds of conditions are signaled. For example, an effect 
equivalent to that of \cdf{ignore-errors} above is achieved in the following example:
\begin{lisp}
Lisp> (setq filename "nosuchfile") \\
~\EV\ "nosuchfile" \\
Lisp> (handler-case (open filename :direction :input) \\
~~~~~~~~(error (condition) \\
~~~~~~~~~~(values nil condition))) \\
~\EV\ NIL \textrm{and} \#<FILE-ERROR 3437525>
\end{lisp}
However, using \cdf{handler-case}, one can indicate a more specific condition
type than just ``error.'' Condition types are explained in detail later, but the
syntax looks roughly like the following:
\begin{lisp}
Lisp> (makunbound 'filename) \\
~\EV\ FILENAME \\
Lisp> (handler-case (open filename :direction :input) \\
~~~~~~~~(file-error (condition) \\
~~~~~~~~~~(values nil condition))) \\
Error: The variable FILENAME is unbound. \\
To continue, type :CONTINUE followed by an option number: \\
~1: Retry getting the value of FILENAME. \\
~2: Specify a value of FILENAME to use this time. \\
~3: Specify a value of FILENAME to store and use. \\
~4: Return to Lisp Toplevel. \\
Debug> 
\end{lisp}

\subsection{Handling Conditions}
\label{HANDLING-CONDITIONS}

Blind transfer of control to a \cdf{handler-case} is only one possible kind
of recovery action that can be taken when a condition is signaled.  The
low-level mechanism offers great flexibility in how to continue once
a condition has been signaled.

The basic idea behind condition handling is that a piece of code called the
\emph{signaler} recognizes and announces the existence of an exceptional
situation using \cdf{signal} or some function built on \cdf{signal} (such as
\cdf{error}). 

The process of signaling involves the search for and invocation of a
\emph{handler}, a piece of code that will attempt to deal appropriately with
the situation. 

If a handler is found, it may either \emph{handle} the situation, by performing
some non-local transfer of control, or \emph{decline} to handle it, by failing to perform a
non-local transfer of control. If it declines, other handlers are sought.

Since the lexical environment of the signaler might not be available to
handlers, a data structure called a \emph{condition} is created to represent
explicitly the relevant state of the situation. A condition either is created
explicitly using \cdf{make-condition} and then passed to a function such as \cdf{signal},
or is created implicitly by a function such as \cdf{signal} when given appropriate
non-condition arguments.

In order to handle the error, a handler is permitted to use any non-local
transfer of control such as \cdf{go} to a tag in a \cdf{tagbody},
\cdf{return} from a \cdf{block}, or
\cdf{throw} to a \cdf{catch}. In addition, structured abstractions of these
primitives are provided for convenience in exception handling.

A handler can be made dynamically accessible to a program by use of
\cdf{handler-bind}. For example, to create a handler for a condition of type
\cdf{arithmetic-error}, one might write:
\begingroup
\makeatletter
\def\@listi{\leftmargin\leftmargini \labelsep\leftmargin
   \parsep 3pt\relax
   \topsep 4pt plus 9pt\relax
   \itemsep\topsep}
\makeatother
\begin{lisp}
(handler-bind ((arithmetic-error \emph{handler}))\emph{body})
\end{lisp}
The handler is a function of one argument, the condition. If a condition of
the designated type is signaled while the \emph{body} is executing (and there are no
intervening handlers), the handler would be invoked on the given condition,
allowing it the option of transferring control. For example, one might write a
macro that executes a body, returning either its value(s) or the two values
\cdf{nil} and the condition:
\begin{lisp}
(defmacro without-arithmetic-errors (\&body forms) \\
~~(let ((tag (gensym))) \\
~~~~`(block ,tag \\
~~~~~~ (handler-bind ((arithmetic-error \\
~~~~~~~~~~~~~~~~~~~~~~~~~\#'(lambda (c)~~~~~;\textrm{Argument \cdf{c} is a condition} \\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (return-from ,tag (values nil c))))) \\
~~~~~~~~~,@body)))) \\
\end{lisp}
\endgroup
The handler is executed in the dynamic context of the signaler, except
that the set of available condition handlers will have been rebound to
the value that was active at the time the condition handler was made
active. If a handler decline (that is, it does not transfer control), other 
handlers are sought. If no handler is found and the condition was signaled
by \cdf{error} or \cdf{cerror} (or some function such as \cdf{assert} that behaves like
these functions), the debugger is entered, still in the dynamic context 
of the signaler.

\subsection{Object-Oriented Basis of Condition Handling}
\label{OBJECT-0RIENTED-BASIS}

Of course, the ability of the handler to usefully handle an exceptional
situation is related to the quality of the information it is provided. For
example, if all errors were signaled by
\begin{lisp}
(error "\emph{some format string}")
\end{lisp}
then the only piece of information that would be accessible to the handler
would be an object of type \cdf{simple-error} that had a slot containing the
format string.

If this were done, \cdf{string-equal} would be the preferred way to tell one error
from another, and it would be very hard to allow flexibility in the
presentation of error messages because existing handlers would tend to be
broken by even tiny variations in the wording of an error message. This
phenomenon has been the major failing of most error systems previously
available in Lisp. It is fundamentally important to decouple the error
message string (the human interface) from the objects that formally
represent the error state (the program interface). We therefore have the
notion of typed conditions, and of formal operations on those conditions
that make them inspectable in a structured way.

This object-oriented approach to condition handling has the following
important advantages over a text-based approach:
\begin{itemize}
\item
   Conditions are classified according to subtype relationships, making
   it easy to test for categories of conditions.

\item
   Conditions have named slot values through which parameters are conveyed
   from the program that signals the condition to the program that handles it.

\item
   Inheritance of methods and slots reduces the amount of explicit
   specification necessary to achieve various interesting effects.
\end{itemize}

Some condition types are defined by this document, but the set of 
condition types is extensible using \cdf{define-condition}.
Common Lisp condition types are in fact CLOS classes, and condition objects
are ordinary CLOS objects; \cdf{define-condition} merely
provides an abstract interface that is a bit more convenient than
\cdf{defclass} for defining conditions.

Here, as an example,
we define a two-argument function called \cdf{divide} that is patterned after
the \cdf{/} function but does some stylized error checking:
\begin{lisp}
(defun divide (numerator denominator) \\
~~(cond ((or (not (numberp numerator)) \\
~~~~~~~~~~~~~(not (numberp denominator))) \\
~~~~~~~~~(error "(DIVIDE '{\Xtilde}S '{\Xtilde}S) - Bad arguments." \\
~~~~~~~~~~~~~~~~numerator denominator)) \\
~~~~~~~~((zerop denominator) \\
~~~~~~~~~(error 'division-by-zero \\
~~~~~~~~~~~~~~~~:operator 'divide \\
~~~~~~~~~~~~~~~~:operands (list numerator denominator))) \\
~~~~~~~~(t ...)))
\end{lisp}
Note that in the first clause we have used \cdf{error} with a string argument
and in the second clause we have named a particular condition type,
\cdf{division-by-zero}. In the case of a string argument, the condition type that
will be signaled is \cdf{simple-error}.

The particular kind of error that is signaled may be important
in cases where handlers are active. For example, \cdf{simple-error} inherits 
from type \cdf{error}, which in turn inherits from type \cdf{condition}. On the 
other hand, \cdf{division-by-zero} inherits from \cdf{arithmetic-error}, which 
inherits from \cdf{error}, which inherits from \cdf{condition}. So if a handler
existed for \cdf{arithmetic-error} while a \cdf{division-by-zero} condition was
signaled, that handler would be tried; however, if a \cdf{simple-error}
condition were signaled in the same context, the handler for type
\cdf{arithmetic-error} would not be tried.

\subsection{Restarts}
\label{RESTARTS}

The Common Lisp Condition System creats a clear
separation between the act of signaling an error of a particular type and the
act of saying that a particular way of recovery is appropriate. In the \cdf{divide}
example above, simply signaling an error does not imply a willingness on the
part of the signaler to cooperate in any corrective action. For example, the
following sample interaction illustrates that the only recovery action
offered for this error is ``Return to Lisp Toplevel'':
\begin{lisp}
Lisp> (+ (divide 3 0) 7) \\
Error: Attempt to divide 3 by 0. \\
To continue, type :CONTINUE followed by an option number: \\
~1: Return to Lisp Toplevel. \\
Debug> :continue 1 \\
Returned to Lisp Toplevel. \\
Lisp>
\end{lisp}
When an error is detected and the function \cdf{error} is called, execution cannot
continue normally because \cdf{error} will not directly return. Control can be
transferred to other points in the program, however, by means of specially
established ``restarts.''

\subsection{Anonymous Restarts}

The simplest kind of restart involves structured transfer of control using
a macro called \cdf{restart-case}. The \cdf{restart-case} form allows execution of
a piece of code in a context where zero or more restarts are active, and
where if one of those restarts is ``invoked,'' control will be transferred
to the corresponding clause in the \cdf{restart-case} form. For example, we could
rewrite the previous \cdf{divide} example as follows.
\begin{lisp}
(defun divide (numerator denominator) \\
~~(loop \\
~~~~(restart-case \\
~~~~~~~~(return \\
~~~~~~~~~~(cond ((or (not (numberp numerator)) \\
~~~~~~~~~~~~~~~~~~~~~(not (numberp denominator))) \\
~~~~~~~~~~~~~~~~~(error "(DIVIDE '{\Xtilde}S '{\Xtilde}S) - Bad arguments." \\
~~~~~~~~~~~~~~~~~~~~~~~~~numerator denominator)) \\
~~~~~~~~~~~~~~~~((zerop denominator) \\
~~~~~~~~~~~~~~~~~(error 'division-by-zero \\
~~~~~~~~~~~~~~~~~~~~~~~~:operator 'divide \\
~~~~~~~~~~~~~~~~~~~~~~~~:operands (list numerator denominator))) \\
~~~~~~~~~~~~~~~~(t ...))) \\
~~~~~~(nil (arg1 arg2) \\
~~~~~~~~~~:report "Provide new arguments for use by DIVIDE." \\
~~~~~~~~~~:interactive \\
~~~~~~~~~~~~(lambda () \\
~~~~~~~~~~~~~~~(list (prompt-for 'number "Numerator: ") \\
~~~~~~~~~~~~~~~~~~~~~(prompt-for 'number "Denominator: "))) \\
~~~~~~~~(setq numerator arg1 denominator arg2)) \\
~~~~~~(nil (result) \\
~~~~~~~~~~:report "Provide a value to return from DIVIDE." \\
~~~~~~~~~~:interactive \\
~~~~~~~~~~~~(lambda () (list (prompt-for 'number "Result: "))) \\
~~~~~~~~(return result)))))
\end{lisp}

\beforenoterule
\begin{sideremark}
    The function \cdf{prompt-for} used in this chapter in a number of places is
    not a part of Common Lisp.  It is used in the examples in this chapter only to keep
    the presentation simple.  It is assumed to accept a type specifier
     and optionally a format string and associated arguments.  It uses the
    format string and associated arguments as part of an interactive prompt,
    and uses \cdf{read} to read a Lisp object; however, only an object of the
    type indicated by the type specifier is accepted.

    The question of whether or not \cdf{prompt-for} (or something like it) would be a
    useful addition to Common Lisp is under consideration by X3J13, but as of
    January 1989 no action has been taken. In spite of its use in a number of examples,
    nothing in the Common Lisp Condition System depends on this function.
\end{sideremark}
\afternoterule

In the example, the \cdf{nil} at the head of each clause
means that it is an ``anonymous'' restart.
Anonymous restarts are typically invoked only from within the
debugger. As we shall see later, it is possible to have ``named restarts''
that may be invoked from code without the need for user intervention.

If the arguments to anonymous restarts are not optional, then special
information must be provided about what the debugger should use as arguments.
Here the \cd{:interactive} keyword is used to specify that information.

The \cd{:report} keyword introduces information to be used when presenting the
restart option to the user (by the debugger, for example).

Here is a sample interaction that takes advantage of the restarts provided
by the revised definition of \cdf{divide}:
\begin{lisp}
Lisp> (+ (divide 3 0) 7) \\
Error: Attempt to divide 3 by 0. \\
To continue, type :CONTINUE followed by an option number: \\
~1: Provide new arguments for use by the DIVIDE function. \\
~2: Provide a value to return from the DIVIDE function. \\
~3: Return to Lisp Toplevel. \\
Debug> :continue 1 \\
1 \\
Numerator: 4 \\
Denominator: 2 \\
~\EV\ 9
\end{lisp}

\subsection{Named Restarts}

In addition to anonymous restarts, one can have named restarts, which can be invoked
by name from within code.  As a trivial example, one could write
\begin{lisp}
(restart-case (invoke-restart 'foo 3) \\
~~(foo (x) (+ x 1)))
\end{lisp}
to add \cd{3} to \cd{1}, returning \cd{4}. This trivial example is conceptually analogous to 
writing:
\begin{lisp}
(+ (catch 'something (throw 'something 3)) 1)
\end{lisp}

For a more realistic example, the code for the function \cdf{symbol-value} might signal an
unbound variable error as follows:
\begin{lisp}
(restart-case (error "The variable {\Xtilde}S is unbound." variable) \\*
~~(continue () \\*
~~~~~~:report \\*
~~~~~~~~(lambda (s)~~~~~;\textrm{Argument \cdf{s} is a stream} \\*
~~~~~~~~~~(format s "Retry getting the value of {\Xtilde}S." variable)) \\*
~~~~(symbol-value variable)) \\
~~(use-value (value) \\*
~~~~~~:report \\*
~~~~~~~~(lambda (s)~~~~~;\textrm{Argument \cdf{s} is a stream} \\*
~~~~~~~~~~(format s "Specify a value of {\Xtilde}S to use this time." \\*
~~~~~~~~~~~~~~~~~~variable)) \\*
~~~~value) \\
~~(store-value (value) \\*
~~~~~~:report \\*
~~~~~~~~(lambda (s)~~~~~;\textrm{Argument \cdf{s} is a stream} \\*
~~~~~~~~~~(format s "Specify a value of {\Xtilde}S to store and use." \\*
~~~~~~~~~~~~~~~~~~variable)) \\*
~~~~(setf (symbol-value variable) value) \\*
~~~~value))
\end{lisp}
If this were part of the implementation of \cdf{symbol-value}, then it would be possible
for users to write a variety of automatic handlers for unbound variable
errors. For example, to make unbound variables evaluate to themselves, one
might write
\begin{lisp}
(handler-bind ((unbound-variable \\
~~~~~~~~~~~~~~~~~\#'(lambda (c)~~~~~;\textrm{Argument \cdf{c} is a condition} \\
~~~~~~~~~~~~~~~~~~~~~(when (find-restart 'use-value) \\
~~~~~~~~~~~~~~~~~~~~~~~(invoke-restart 'use-value \\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(cell-error-name c)))))) \\
~~\emph{body})
\end{lisp}

\subsection{Restart Functions}

For commonly used restarts, it is conventional to define a program interface
that hides the use of \cdf{invoke-restart}. Such program interfaces to restarts
are called \emph{restart functions}.

The normal convention is for the function to share the name of the restart.
The pre-defined functions \cdf{abort}, \cdf{continue}, \cdf{muffle-warning}, \cdf{store-value}, and
\cdf{use-value} are restart functions. With \cdf{use-value} the above example of 
\cdf{handler-bind} could have been written more concisely as
\begin{lisp}
(handler-bind ((unbound-variable \\
~~~~~~~~~~~~~~~~~~~\#'(lambda (c)~~~~~;\textrm{Argument \cdf{c} is a condition} \\
~~~~~~~~~~~~~~~~~~~~~~~(use-value (cell-error-name c))))) \\
~~\emph{body})
\end{lisp}

\subsection{Comparison of Restarts and Catch/Throw}
  
One important feature that \cdf{restart-case} (or \cdf{restart-bind}) offers that
\cdf{catch} does not is the ability to reason about the available points to
which control might be transferred without actually attempting the
transfer. One could, for example, write
\begin{lisp}
(ignore-errors (throw ...))
\end{lisp}
which is a sort of poor man's variation of
\begin{lisp}
(when (find-restart 'something) \\*
~~(invoke-restart 'something))
\end{lisp}
but there is no way to use \cdf{ignore-errors} and \cdf{throw} to simulate something
like
\begin{lisp}
(when (and (find-restart 'something) \\*
~~~~~~~~~~~(find-restart 'something-else)) \\*
~~(invoke-restart 'something))
\end{lisp}
or even just
\begin{lisp}
(when (and (find-restart 'something) \\
~~~~~~~~~~~(yes-or-no-p "Do something? ")) \\
~~(invoke-restart 'something))
\end{lisp}
because the degree of inspectability that comes with simply writing
\begin{lisp}
(ignore-errors (throw ...))
\end{lisp}
is too primitive---getting the desired information also forces
transfer of control, perhaps at a time when it is not desirable.

Many programmers have previously evolved strategies like the following
on a case-by-case basis:
\begin{lisp}
(defvar *foo-tag-is-available* nil) \\
\\
(defun fn-1 () \\
~~(catch 'foo \\
~~~~(let ((*foo-tag-is-available* t)) \\
~~~~~~... (fn-2) ...))) \\
\\
(defun fn-2 () \\
~~... \\
~~(if *foo-tag-is-available* (throw 'foo t)) \\
~~...)
\end{lisp}
The facility provided by \cdf{restart-case} and \cdf{find-restart} is intended to
provide a standardized protocol for this sort of information to be
communicated between programs that were developed independently so that
individual variations from program to program
do not thwart the overall modularity and debuggability of programs.

Another difference between the restart facility and the \cdf{catch}/\cdf{throw}
facility is that a \cdf{catch} with any given tag completely shadows any
outer pending \cdf{catch} that uses the same tag. Because of the presence
of \cdf{compute-restarts}, however, it is possible to see shadowed restarts,
which may be very useful in some situations (particularly in an
interactive debugger).

\subsection{Generalized Restarts}
\label{LAST-RESTARTS-SECTION}

\cdf{restart-case} is a mechanism that allows only imperative transfer of control
for its associated restarts. \cdf{restart-case} is built on a lower-level mechanism
called \cdf{restart-bind}, which does not force transfer of control.

\cdf{restart-bind} is to \cdf{restart-case} as \cdf{handler-bind} is to
\cdf{handler-case}.
The syntax is
\begin{lisp}
(restart-bind ((\emph{name} \emph{function} . \emph{options})) . \emph{body})
\end{lisp}
The \emph{body} is executed in a dynamic context within which the \emph{function}
will be called whenever 
\cd{(invoke-restart '\emph{name})} is executed. The \emph{options} are keyword-style and are
used to pass information such as that provided with the
\cd{:report} keyword in \cdf{restart-case}.

A \cdf{restart-case} expands into a call to \cdf{restart-bind} where the function
simply does an unconditional transfer of control to a particular body
of code, passing along ``argument'' information in a structured way.

It is also possible to write restarts that do not transfer control. Such
restarts may be useful in implementing various special commands for the
debugger that are of interest only in certain situations. For example,
one might imagine a situation where file space was exhausted and the
following was done in an attempt to free space in directory \cdf{dir}:
\begin{lisp}
(restart-bind ((nil \#'(lambda () (expunge-directory dir)) \\
~~~~~~~~~~~~~~~~~~~~:report-function \\
~~~~~~~~~~~~~~~~~~~~~~\#'(lambda (stream) \\
~~~~~~~~~~~~~~~~~~~~~~~~~~(format stream "Expunge {\Xtilde}A." \\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(directory-namestring dir))))) \\
~~(cerror "Try this file operation again." \\
~~~~~~~~~~'directory-full :directory dir))
\end{lisp}
In this case, the debugger might be entered and the user could first
perform the expunge (which would not transfer control from the debugger
context) and then retry the file operation:
\begin{lisp}
Lisp> (open "FOO" :direction :output) \\
Error: The directory PS:<JDOE> is full. \\
To continue, type :CONTINUE followed by an option number: \\
~1: Try this file operation again. \\
~2: Expunge PS:<JDOE>. \\
~3: Return to Lisp Toplevel. \\
Debug> :continue 2 \\
Expunging PS:<JDOE> ... 3 records freed. \\
Debug> :continue 1 \\
~\EV\ \#<OUTPUT-STREAM "PS:<JDOE>FOO.LSP" 2323473>
\end{lisp}

\subsection{Interactive Condition Handling}

When a program does not know how to continue, and no active handler is able to
advise it, the ``interactive condition handler,'' or ``debugger,'' can be
entered. This happens implicitly through the use of functions such as \cdf{error}
and \cdf{cerror}, or explicitly through the use of the function
\cdf{invoke-debugger}.

The interactive condition handler never returns directly; it returns only
through structured non-local transfer of control to specially defined restart
points that can be set up either by the system or by user code. The
mechanisms that support the establishment of such structured restart points
for portable code are outlined
in sections~\ref{RESTARTS} through~\ref{LAST-RESTARTS-SECTION}.

Actually, implementations may also provide extended debugging facilities that
allow return from arbitrary stack frames. Although such commands are frequently
useful in practice, their effects are implementation-dependent because they
violate the Common Lisp program abstraction. The effect of using such
commands is undefined with respect to Common Lisp.

\subsection{Serious Conditions}

The \cdf{ignore-errors} macro will trap conditions of type \cdf{error}. There are,
however, conditions that are not of type \cdf{error}.

Some conditions are not considered errors but are still very serious, so
we call them \emph{serious conditions} and we use the type \cdf{serious-condition} to
represent them. Conditions such as those that might be signaled for
``stack overflow'' or ``storage exhausted'' are in this category.

The type \cdf{error} is a subtype of \cdf{serious-condition}, and it would technically
be correct to use the term ``serious condition'' to refer to all serious
conditions whether errors or not. However, normally we use the term 
``serious condition'' to refer to things of type \cdf{serious-condition} but not
of type \cdf{error}.

The point of the distinction between errors and other serious conditions
is that some conditions are known to occur for reasons that are beyond the
scope of Common Lisp to specify clearly. For example, we know that a stack
will generally be used to implement function calling, and we know that stacks
tend to be of finite size and are prone to overflow. Since the available
stack size may vary from implementation to implementation, from session
to session, or from function call to function call, it would be confusing
to have expressions such as \cd{(ignore-errors (+~a~b))} return a number sometimes
and \cdf{nil} other times if \cdf{a} and \cdf{b} were always bound to numbers and the stack
just happened to overflow on a particular call. For this reason, only
conditions of type \cdf{error} and not all conditions of type \cdf{serious-condition}
are trapped by \cdf{ignore-errors}. To trap other conditions, a lower-level
facility must be used (such as \cdf{handler-bind} or \cdf{handler-case}).

By convention, the function \cdf{error} is preferred over \cdf{signal} to signal conditions
of type \cdf{serious-condition} (including those of type \cdf{error}). It is the use of
the function \cdf{error}, and not the type of the condition being signaled, that
actually causes the debugger to be entered.

\subsection{Non-Serious Conditions}

Some conditions are neither errors nor serious conditions. They are signaled
to give other programs a chance to intervene, but if no action is taken,
computation simply continues normally.

For example, an implementation might choose to signal a non-serious (and
implementation-dependent) condition
called \cdf{end-of-line} when output reaches the last character position on a line
of character output. In such an implementation, the signaling of this
condition might allow a convenient way for other programs to intervene,
producing output that is truncated at the end of a line.

By convention, the function \cdf{signal} is used to signal conditions that are not
serious. It would be possible to signal serious conditions using \cdf{signal}, and
the debugger would not be entered if the condition went unhandled.  However,
by convention,
handlers will generally tend to assume that serious conditions and errors
were signaled by calling the \cdf{error} function (and will therefore
force entry to the interactive condition handler) and that they should
work to avoid this.

\subsection{Condition Types}
 
Some types of conditions are predefined by the system. All types of conditions
are subtypes of \cdf{condition}. That is, \cd{(typep~\emph{x} 'condition)} is true if
and only if the value of \emph{x} is a condition. 

Implementations supporting multiple (or non-hierarchical) type inheritance
are expressly permitted to exploit multiple inheritance in the tree of
condition types as implementation-dependent extensions, as long as such
extensions are compatible with the specifications in this chapter.
[X3J13 voted in March 1989 \issue{ZLOS-CONDITIONS}
to integrate the Condition System and the Object System,
so multiple inheritance is always available for condition types.---GLS]

In order to avoid problems in portable code that runs both in systems with
multiple type inheritance and in systems without it, programmers are explicitly
warned that while all correct Common Lisp implementations will ensure that
\cd{(typep~\emph{c} 'condition)}
is true for all conditions \emph{c} (and all subtype relationships indicated in this
chapter will also be true), it should \emph{not} be assumed that two condition
types specified to be subtypes of the same third type are disjoint.
(In some cases,
disjoint subtypes are identified explicitly, but such disjointness is not to be assumed by
default.)  For example, it follows from the subtype descriptions contained in
this chapter that in all implementations
\cd{(typep~\emph{c}~'control-error)} implies \cd{(typep~\emph{c}~'error)},
but note that
\cd{(typep~\emph{c}~'control-error)} does \emph{not}
imply \cd{(not~(typep~\emph{c}~'cell-error))}.


\subsection{Signaling Conditions}

When a condition is signaled, the system tries to locate the most appropriate
handler for the condition and to invoke that handler.

Handlers are established dynamically using \cdf{handler-bind} or abstractions built
on \cdf{handler-bind}.

If an appropriate handler is found, it is called. In some circumstances, 
the handler may \emph{decline} simply by returning without performing a 
non-local transfer of control. In such cases, the search for an 
appropriate handler is picked up where it left off, as if the called 
handler had never been present.

If no handler is found, or if all handlers that were found decline,
\cdf{signal} returns \cdf{nil}.

Although it follows from the description above, it is perhaps worth noting
explicitly that the lookup procedure described here will prefer a general 
but more (dynamically) local handler over a specific but less (dynamically)
local handler. Experience with existing condition systems suggests that
this is a reasonable approach and works adequately in most situations. 
Some care should be taken when binding handlers for very general kinds of
conditions, such as is done in \cdf{ignore-errors}. Often, binding for a more
specific condition type than \cdf{error} is more appropriate.

\subsection{Resignaling Conditions}
 
[The contents of this section are still a subject of some debate within X3J13.
The reader may wish to take this section with a grain of salt.---GLS]

Note that signaling a condition has no side effect on that condition, and
that there is no dynamic state contained in a condition object. As such, it
may at times be reasonable and appropriate to consider caching condition
objects for repeated use, re-signaling conditions from within handlers,
or saving conditions away somewhere and re-signaling them later.

For example, it may be desirable for the system to pre-allocate objects of type
\cdf{storage-condition} so that they can be signaled when needed without
attempting to allocate more storage.

\subsection{Condition Handlers}
\label{CONDITION-HANDLERS}

A \emph{handler} is a function of one argument, the condition to be handled. The
handler may inspect the object
to be sure it is ``interested'' in handling the condition.

A handler is executed in the dynamic context of the signaler, except that the
set of available condition handlers will have been rebound to the value that
was active at the time the condition handler was made active. The intent of
this is to prevent infinite recursion because of errors in a condition handler.

After inspecting the condition, the handler should take one of the following
actions:
\begin{itemize}
  \item
    It might \emph{decline} to handle the condition (by simply returning). When
    this happens, the returned values are ignored and the effect is the same
    as if the handler had been invisible to the mechanism seeking to find a
    handler. The next handler in line will be tried, or if no such handler
    exists, the condition will go unhandled.

  \item
    It might \emph{handle} the condition (by performing some non-local transfer
    of control). This may be done either primitively using \cdf{go}, \cdf{return}, or \cdf{throw},
    or more abstractly using a function such as \cdf{abort} or \cdf{invoke-restart}.

  \item
    It might signal another condition.

  \item
    It might invoke the interactive debugger.
\end{itemize}
In fact, the latter two actions (signaling another condition or entering the
debugger) are really just ways of putting off the decision to either handle
or decline, or trying to get someone else to make such a decision. Ultimately,
all a handler can do is to handle or decline to handle.

\subsection{Printing Conditions}

When \cdf{*print-escape*} is \cdf{nil} (for example,
when the \cdf{princ} function or the \cd{{\Xtilde}A}
directive is used with \cdf{format}), the report method for the condition will be invoked. This will
be done automatically by functions such as \cdf{invoke-debugger}, \cdf{break}, and \cdf{warn},
but there may still be situations in which it is desirable to have a
condition report under explicit user control. For example,
\begin{lisp}
(let ((form '(open "nosuchfile"))) \\
~~(handler-case (eval form) \\
~~~~(serious-condition (c) \\
~~~~~~(format t "{\Xtilde}\&Evaluation of {\Xtilde}S failed:{\Xtilde}\%{\Xtilde}A" form c))))
\end{lisp}
might print something like
\begin{lisp}
Evaluation of (OPEN "nosuchfile") failed: \\
The file "nosuchfile" was not found.
\end{lisp}
Some suggestions about the form of text typed by report methods:
\begin{itemize}
 \item
    The message should generally be a complete sentence, beginning with a
   capital letter and ending with appropriate punctuation (usually a period).

 \item
    The message should \emph{not} include any introductory text such as ``\cd{Error:}''
   or ``\cd{Warning:}'' and should not be followed by a trailing newline. Such
   text will be added as may be appropriate to context by the routine invoking
   the report method.

 \item
    Except where unavoidable, the tab character (which is only semi-standard anyway)
    should not be used in
   error messages. Its effect may vary from one implementation to another and may
   cause problems even within an implementation because it may do different
   things depending on the column at which the error report begins.

 \item
    Single-line messages are preferred, but newlines in the middle of long
   messages are acceptable.

 \item
   If any program (for example, the debugger) displays messages indented from the
   prevailing left margin (for example, indented seven spaces because they
   are prefixed by the seven-character herald ``\cd{Error:~}''), then that program
   will take care of inserting the appropriate indentation into the extra
   lines of a multi-line error message. Similarly, a program that prefixes
   error messages with semicolons so that they appear to be comments should
   take care of inserting a semicolon at the beginning of each line in a
   multi-line error message. (These rules are important because, even within
   a single implementation, there may be more than one program that presents
   error messages to the user, and they may use different styles of
   presentation. The caller of \cdf{error} cannot anticipate all such possible
   styles, and so it is incumbent upon the presenter of the message to make
   any necessary adjustments.)
\end{itemize}
% [Note: These recommendations expand upon those in
% section~\ref{ERROR-SIGNALLING-FUNCTIONS}.---GLS]

When \cdf{*print-escape*} is not \cdf{nil}, the object should print in some useful (but
usually fairly abbreviated) fashion according to the style of the
implementation. It is not expected that a condition will be printed in a form
suitable for \cdf{read}. Something like \cd{\#<ARITHMETIC-ERROR~1734>}
is fine.

X3J13 voted in March 1989 \issue{ZLOS-CONDITIONS} to integrate the
Condition System and the Object System.
In the original Condition System proposal,
no function was provided for directly accessing or setting the printer for
a condition type, or for invoking it; the techniques described above were
the sole interface to reporting.  The vote specified that, in CLOS terms,
condition reporting is mediated through the \cdf{print-object}
method for the condition type (that is, class) in question, with \cdf{*print-escape*}
bound to \cdf{nil}.

Specifying \cd{(:report \emph{fn})} to
\cdf{define-condition} when defining
condition type \emph{C} is equivalent to a separate method definition:
\begin{lisp}
(defmethod print-object ((x \emph{C}) stream) \\*
~~(if *print-escape* \\*
~~~~~~(call-next-method) \\*
~~~~~~(funcall \#'\emph{fn} x stream)))
\end{lisp}
Note that the method uses \emph{fn} to print the condition
only when \cdf{*print-escape*} has the value \cdf{nil}.

\section{Program Interface to the Condition System}

This section describes functions, macros, variables, and condition
types associated with the Common Lisp Condition System.

\subsection{Signaling Conditions}
\label{SIGNALLING-CONDITIONS}

The functions in this section provide various mechanisms
for signaling warnings, breaks, continuable errors, and fatal errors.

\begin{defun}[Function]
error datum &rest arguments

Invokes the signal facility on a condition. If the condition is not handled,
\cd{(invoke-debugger \emph{condition})} is executed. As a consequence of calling 
\cdf{invoke-debugger}, \cdf{error} never directly returns to its caller; the only exit from this
function can come by non-local transfer of control in a handler or by use of
an interactive debugging command.
  
If \emph{datum} is a condition, then that condition is used directly. 
In this case, it is an error for the list of \emph{arguments} to be non-empty;
that is, \cdf{error} must have been called with exactly one argument, the condition.

If \emph{datum} is a condition type (a class or class name), then the condition used is effectively the result
of \cd{(apply \#'make-condition \emph{datum} \emph{arguments})}.

If \emph{datum} is a string, then the condition used is effectively the result of
\begin{lisp}
(make-condition 'simple-error \\*
~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
~~~~~~~~~~~~~~~~:format-arguments \emph{arguments})
\end{lisp}
\end{defun}

\begin{defun}[Function]
cerror continue-format-string datum &rest arguments

The function \cdf{cerror}
invokes the error facility on a condition. If the condition is not handled,
\cd{(invoke-debugger \emph{condition})} is executed. While signaling is going on,
and
while control is in the debugger (if it is reached), it is possible to continue
program execution (thereby returning from the call to \cdf{cerror})
using the \cdf{continue} restart.

If \emph{datum} is a condition, then that condition is used directly. 
In this case, the list of \emph{arguments} need not be empty,
but will be used only with the \emph{continue-format-string}
and will not be used to initialize \emph{datum}.

If \emph{datum} is a condition type (a class or class name), then the condition
used is effectively the result of \cd{(apply \#'make-condition \emph{datum}
  \emph{arguments})}.

If \emph{datum} is a string, then the condition used is effectively the result of
\begin{lisp}
(make-condition 'simple-error \\*
~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
~~~~~~~~~~~~~~~~:format-arguments \emph{arguments})
\end{lisp}

The \emph{continue-format-string} must be a string.
Note that if \emph{datum} is not a 
string, then the format arguments used by the \emph{continue-format-string} will
still be the list of \emph{arguments} (which is in keyword format if \emph{datum} is a condition
type). In this case, some care may be necessary to set up the
\emph{continue-format-string} correctly. The \cdf{format} directive \cd{{\Xtilde}*},
which ignores and skips over \cdf{format} arguments,
may be particularly 
useful in this situation.

The value returned by \cdf{cerror} is \cdf{nil}.
\end{defun}

\begin{defun}[Function]
signal datum &rest arguments

Invokes the signal facility on a condition. If the condition is not handled,
\cdf{signal} returns \cdf{nil}.

If \emph{datum} is a condition, then that condition is used directly. 
In this case, it is an error for the list of \emph{arguments} to be non-empty;
that is, \cdf{signal} must have been called with exactly one argument, the condition.

If \emph{datum} is a condition type (a class or class name), then the condition used is effectively the result
of \cd{(apply \#'make-condition \emph{datum} \emph{arguments})}.

If \emph{datum} is a string, then the condition used is effectively the result of
\begin{lisp}
  (make-condition 'simple-error \\*
  ~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
  ~~~~~~~~~~~~~~~~:format-arguments \emph{arguments})
\end{lisp}

Note that if \cd{(typep \emph{condition} *break-on-signals*)} is true, then the debugger
will be entered prior to beginning the process of signaling. The \cdf{continue}
restart function may be used to continue with the signaling process;
the restart is associated with the signaled condition as if by
use of \cdf{with-condition-restarts}.
This is true
also for all other functions and macros that signal conditions, such
as \cdf{warn}, \cdf{error}, \cdf{cerror}, \cdf{assert}, and \cdf{check-type}.

During the dynamic extent of a call to \cdf{signal} with a
particular condition, the effect of calling \cdf{signal} again on that
condition object for a distinct abstract event is not defined.
For example, although a handler \emph{may} resignal a condition in order to
allow outer handlers first shot at handling the condition, two
distinct asynchronous keyboard events must not signal an the same (\cdf{eq}) condition
object at the same time.

For further details about signaling and handling, see the discussion of
condition handlers in section~\ref{CONDITION-HANDLERS}.
\end{defun}


\begin{defun}[Variable]
*break-on-signals*

This variable is intended primarily for use when the user is debugging programs
that do signaling.  The value of \cd{*break-on-signals*} should be suitable as a
second argument to \cdf{typep}, that is, a type or type specifier.

When \cd{(typep \emph{condition} *break-on-signals*)} is true, then calls to
\cdf{signal} (and to other advertised functions such as \cdf{error} that
implicitly call \cdf{signal}) will enter the debugger prior to signaling that
\emph{condition}. The \cdf{continue} restart may be used to continue with the
normal signaling process; the restart is associated with the signaled condition
as if by use of \cdf{with-condition-restarts}.

Note that \cdf{nil} is a valid type specifier.  If the value of
\cdf{*break-on-signals*} is \cdf{nil}, then \cdf{signal} will never enter the
debugger in this implicit manner.

When setting this variable, the user is encouraged to choose the most
restrictive specification that suffices. Setting this flag effectively violates
the modular handling of condition signaling that this chapter seeks to
establish. Its complete effect may be unpredictable in some cases, since the
user may not be aware of the variety or number of calls to \cdf{signal} that are
used in programs called only incidentally.

By default---and certainly in any ``production'' use---the value of this
variable should be \cdf{nil}, both for reasons of performance and for reasons of
modularity and abstraction.
\end{defun}

\subsection{Assertions}
\label{CONDITION-ASSERTIONS}

These facilities are designed to make it convenient for the user
to insert error checks into code.

\begin{defmac}
check-type place typespec [string]

A \cdf{check-type} form signals an error of type \cdf{type-error} if the
contents of \emph{place} are not of the desired type.

If a condition is signaled, handlers of this condition can use the functions
\cdf{type-error-datum} and \cdf{type-error-expected-type} to access the contents
of \emph{place} and the \emph{typespec}, respectively.

This function can return only if the \cdf{store-value} restart is invoked,
either explicitly from a handler or implicitly as one of the options offered by
the debugger.  The restart is associated with the signaled condition as if by
use of \cdf{with-condition-restarts}.

If \cdf{store-value} is called, \cdf{check-type} will store the new value that
is the argument to \cdf{store-value} (or that is prompted for interactively by
the debugger) in \emph{place} and start over, checking the type of the new value
and signaling another error if it is still not the desired type. Subforms of
\emph{place} may be evaluated multiple times because of the implicit loop
generated. \cdf{check-type} returns \cdf{nil}.

The \emph{place} must be a generalized variable reference acceptable to
\cdf{setf}. The \emph{typespec} must be a type specifier; it is not evaluated.
The \cdf{string} should be an English description of the type, starting with an
indefinite article (``a'' or ``an''); it is evaluated. If the \emph{string} is
not supplied, it is computed automatically from the \emph{typespec}. (The
optional \emph{string} argument is allowed because some applications of
\cdf{check-type} may require a more specific description of what is wanted than
can be generated automatically from the type specifier.)

The error message will mention the \emph{place}, its contents, and the desired
type.

\beforenoterule
\begin{implementation}
  An implementation may choose to generate a somewhat differently worded error
  message if it recognizes that \emph{place} is of a particular form, such as
  one of the arguments to the function that called \cdf{check-type}.
\end{implementation}
\afternoterule

\begin{lisp}
Lisp> (setq aardvarks '(sam harry fred)) \\*
~\EV\ (SAM HARRY FRED) \\
Lisp> (check-type aardvarks (array * (3))) \\*
Error: The value of AARDVARKS, (SAM HARRY FRED), \\*
~~~~~~~is not a 3-long array. \\
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify a value to use instead. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 1 \\*
Use Value: \#(sam fred harry) \\*
~\EV\ NIL \\
Lisp> aardvarks \\*
~\EV\ \#<ARRAY-3 13571> \\
Lisp> (map 'list \#'identity aardvarks) \\*
~\EV\ (SAM FRED HARRY) \\
Lisp> (setq aacount 'foo) \\*
~\EV\ FOO \\
Lisp> (check-type aacount (integer 0 *) "a non-negative integer") \\*
Error: The value of AACOUNT, FOO, is not a non-negative integer. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify a value to use instead. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 2 \\*
Lisp> 
\end{lisp}
\end{defmac}

\begin{defmac}
assert test-form [({place}*) [datum {argument}*]]

An \cdf{assert} form signals an error if the value of the \emph{test-form} is
\cdf{nil}.  Continuing from this error using the \cdf{continue} restart will
allow the user to alter the values of some variables, and \cdf{assert} will then
start over, evaluating the \emph{test-form} again.  (The restart is associated
with the signaled condition as if by use of \cdf{with-condition-restarts}.)
\cdf{assert} returns \cdf{nil}.

The \emph{test-form} may be any form. Each \emph{place} (there may be any number
of them, or none) must be a generalized variable reference acceptable to
\cdf{setf}.  These should be variables on which \emph{test-form} depends, whose
values may sensibly be changed by the user in attempting to correct the error.
Subforms of each \emph{place} are evaluated only if an error is signaled, and
may be re-evaluated if the error is re-signaled (after continuing without
actually fixing the problem).

The \emph{datum} and \emph{argument\/}s are evaluated only if an error is to be
signaled, and re-evaluated if the error is to be signaled again.

If \emph{datum} is a condition, then that condition is used directly.  In this
case, it is an error to specify any \emph{argument\/}s.

If \emph{datum} is a condition type (a class or class name), then the condition
used is effectively the result of \cd{(apply \#'make-condition \emph{datum}
  (list \Mstar{argument}))}.

If \emph{datum} is a string, then the condition used is effectively the result
of
\begin{lisp}
(make-condition 'simple-error \\*
~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
~~~~~~~~~~~~~~~~:format-arguments (list \Mstar{argument}))
\end{lisp}

If \emph{datum} is omitted, then a condition of type \cdf{simple-error} is
constructed using the \emph{test-form} as data. For example, the following might
be used:
\begin{lisp}
(make-condition 'simple-error \\
~~:format-string "The assertion {\Xtilde}S failed." \\
~~:format-arguments '(\emph{test-form}))
\end{lisp}
Note that the \emph{test-form} itself, and not its value, is used as the format
argument.

\beforenoterule
\begin{implementation}
  The debugger need not include the \emph{test-form} in the error message, and
  any \emph{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, an opportunity should be presented to alter the values of any or all
  of the references. The details of this depend on the implementation's style of
  user interface, of course.
\end{implementation}
\afternoterule

Here is an example of the use of \cdf{assert}:
\begin{lisp}
(setq x (make-array '(3 5) :initial-element 3)) \\
(setq y (make-array '(3 5) :initial-element 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 {\Xtilde}S by {\Xtilde}S." a b) \\*
~~~~(really-matrix-multiply a b))) \\
 \\
(matrix-multiply x y) \\
Error: Cannot multiply \#<ARRAY-3-5 12345> by \#<ARRAY-3-5 12364>. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify new values. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 1 \\*
Value for A: x \\*
Value for B: (make-array '(5 3) :initial-element 6) \\
~\EV \#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{lisp}
\end{defmac}

\subsection{Exhaustive Case Analysis}
\label{EXHAUSTIVE-CASE-ANALYSIS-CONDITIONS}


The syntax for \cdf{etypecase} and \cdf{ctypecase} is the same as for
\cdf{typecase}, except that no \cdf{otherwise} clause is permitted. Similarly,
the syntax for \cdf{ecase} and \cdf{ccase} is the same as for \cdf{case} except
for the \cdf{otherwise} clause.

\cdf{etypecase} and \cdf{ecase} are similar to \cdf{typecase} and \cdf{case},
respectively, but signal a non-continuable error rather than returning \cdf{nil}
if no clause is selected.

\cdf{ctypecase} and \cdf{ccase} are also similar to \cdf{typecase} and
\cdf{case}, respectively, but signal a continuable error if no clause is
selected.

\begin{defmac}
etypecase keyform {(type {form}*)}*

This control construct is similar to \cdf{typecase}, but no explicit
\cdf{otherwise} or \cdf{t} clause is permitted. If no clause is satisfied,
\cdf{etypecase} signals an error (of type \cdf{type-error}) with a message
constructed from the clauses.  It is not permissible to continue from this
error. To supply an error message, the user should use \cdf{typecase} with an
\cdf{otherwise} clause containing a call to \cdf{error}. The name of this
function stands for ``exhaustive type case'' or ``error-checking type case.''

Example:
\begin{lisp}
Lisp> (setq x 1/3) \\*
~\EV\ 1/3 \\
Lisp> (etypecase x \\*
~~~~~~~~(integer (* x 4)) \\*
~~~~~~~~(symbol~(symbol-value x))) \\
Error: The value of X, 1/3, is neither an integer nor a symbol. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Return to Lisp Toplevel. \\*
Debug>
\end{lisp}
\end{defmac}

\begin{defmac}
ctypecase keyplace {(type {form}*)}*

This control construct is similar to \cdf{typecase}, but no explicit
\cdf{otherwise} or \cdf{t} clause is permitted.

The \emph{keyplace} must be a generalized variable reference acceptable to
\cdf{setf}.  If no clause is satisfied, \cdf{ctypecase} signals an error (of
type \cdf{type-error}) with a message constructed from the clauses. This error
may be continued using the \cdf{store-value} restart. The argument to
\cdf{store-value} is stored in \emph{keyplace} and then \cdf{ctypecase} starts
over, making the type tests again.  Subforms of \emph{keyplace} may be evaluated
multiple times. If the \cdf{store-value} restart is invoked interactively, the
user will be prompted for the value to be used.
  
The name of this function is mnemonic for ``continuable (exhaustive) type
case.''

Example:
\begin{lisp}
Lisp> (setq x 1/3) \\*
~\EV\ 1/3 \\
Lisp> (ctypecase x \\*
~~~~~~~~(integer (* x 4)) \\*
~~~~~~~~(symbol (symbol-value x))) \\
Error: The value of X, 1/3, is neither an integer nor a symbol. \\*
To continue, type :CONTINUE followed by an option number: \\
~1: Specify a value to use instead. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 1 \\*
Use value: 3.7 \\
Error: The value of X, 3.7, is neither an integer nor a symbol. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify a value to use instead. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 1 \\*
Use value: 12 \\*
~\EV\ 48
\end{lisp}
\end{defmac}


\begin{defmac}
ecase keyform {({({key}*) | key} {form}*)}*

This control construct is similar to \cdf{case}, but no explicit \cdf{otherwise}
or \cdf{t} clause is permitted. If no clause is satisfied, \cdf{ecase} signals
an error (of type \cdf{type-error}) with a message constructed from the
clauses. It is not permissible to continue from this error. To supply an error
message, the user should use \cdf{case} with an \cdf{otherwise} clause
containing a call to \cdf{error}.  The name of this function stands for
``exhaustive case'' or ``error-checking case.''

Example:
\begin{lisp}
Lisp> (setq x 1/3) \\*
~\EV\ 1/3 \\
Lisp> (ecase x \\*
~~~~~~~~(alpha (foo)) \\*
~~~~~~~~(omega (bar)) \\*
~~~~~~~~((zeta phi) (baz))) \\
Error: The value of X, 1/3, is not ALPHA, OMEGA, ZETA, or PHI. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Return to Lisp Toplevel. \\*
Debug>
\end{lisp}
\end{defmac}

\begin{defmac}
ccase keyplace {({({key}*) | key} {form}*)}*

This control construct is similar to \cdf{case}, but no explicit \cdf{otherwise}
or \cdf{t} clause is permitted.

The \emph{keyplace} must be a generalized variable reference acceptable to
\cdf{setf}.  If no clause is satisfied, \cdf{ccase} signals an error (of type
\cdf{type-error}) with a message constructed from the clauses. This error may be
continued using the \cdf{store-value} restart. The argument to \cdf{store-value}
is stored in \emph{keyplace} and then \cdf{ccase} starts over, making the type
tests again. Subforms of \emph{keyplace} may be evaluated multiple times. If the
\cdf{store-value} restart is invoked interactively, the user will be prompted
for the value to be used.

The name of this function is mnemonic for ``continuable (exhaustive) case.''

\beforenoterule
\begin{implementation}
  The \cdf{type-error} signaled by \cdf{ccase} and \cdf{ecase} is free to
  choose any representation of the acceptable argument type that it wishes
  for placement in the expected-type slot. It will always work to use type
  \cd{(member . \emph{keys})}, but in some cases it may be more efficient, for example,
  to use a type that represents an integer subrange or a type composed using the
  \cdf{or} type specifier.
\end{implementation}
\afternoterule
\end{defmac}

\subsection{Handling Conditions}

These macros allow a program to gain control when a condition is signaled.

\begin{defmac}
handler-case expression {(typespec ([var]) {form}*)}*

Executes the given \emph{expression} in a context where various specified
handlers are active.

Each \emph{typespec} may be any type specifier. If during the execution of the
\emph{expression} a condition is signaled for which there is an appropriate
clause---that is, one for which \cd{(typep \emph{condition} '\emph{typespec})}
is true---and if there is no intervening handler for conditions of that type,
then control is transferred to the body of the relevant clause (unwinding the
dynamic state appropriately in the process) and the given variable \cdf{var} is
bound to the condition that was signaled. If no such condition is signaled and
the computation runs to completion, then the values resulting from the
\emph{expression} are returned by the \cdf{handler-case} form.

If more than one case is provided, those cases are made accessible in
parallel. That is, in
\begin{lisp}
(handler-case \emph{expression} \\*
~~(\emph{type\SU{1}} (\emph{var\SU{1}}) \emph{form\SU{1}}) \\*
~~(\emph{type\SU{2}} (\emph{var\SU{2}}) \emph{form\SU{2}}))
\end{lisp}
if the first clause (containing \emph{form\SU{1}}) has been selected, the
handler for the second is no longer visible (and vice versa).

The cases are searched sequentially from top to bottom. If a signaled condition
matches more than one case (possible if there is type overlap) the earlier of
the two cases will be selected.

If the variable \emph{var} is not needed, it may be omitted. That is, a clause
such as
\begin{lisp}
(\emph{type} (\emph{var}) (declare (ignore \emph{var})) \emph{form})
\end{lisp}
may be written using the following shorthand notation:
\begin{lisp}
(\emph{type} () \emph{form})
\end{lisp}

If there are no forms in a selected case, the case returns \cdf{nil}.  Note that
\begin{lisp}
(handler-case \emph{expression} \\*
~~(\emph{type\SU{1}} (\emph{var\SU{1}}) . \emph{body\SU{1}}) \\*
~~(\emph{type\SU{2}} (\emph{var\SU{2}}) . \emph{body\SU{2}}) \\*
~~...)
\end{lisp}
is approximately equivalent to
\begin{lisp}
(block \#1=\#:block-1 \\*
~~(let (\#2=\#:var-2) \\*
~~~~(tagbody \\*
~~~~~~(handler-bind ((\emph{type\SU{1}} \=\#'(lambda (temp) \\*
\>~~~~(setq \#2\# temp) \\*
\>~~~~(go \#3=\#:tag-3))) \\
~~~~~~~~~~~~~~~~~~~~~(\emph{type\SU{2}} \=\#'(lambda (temp) \\*
\>~~~~(setq \#2\# temp) \\*
\>~~~~(go \#4=\#:tag-4))) \\*
~~~~~~~~~~~~~~~~~~~~~...) \\*
~~~~~~~~(return-from \#1\# \emph{expression})) \\
~~~~~~\#3\# (return-from \#1\# (let ((\emph{var\SU{1}} \#2\#)) . \emph{body\SU{1}})) \\*
~~~~~~\#4\# (return-from \#1\# (let ((\emph{var\SU{2}} \#2\#)) . \emph{body\SU{2}})) \\*
~~~~~~...)))
\end{lisp}
[Note the use of ``gensyms'' such as \cd{\#:block-1}
as block names, variables, and \cdf{tagbody} tags in this example,
and the use of \cd{\#\emph{n}=} and \cd{\#\emph{n}\#} read-macro syntax
to indicate that the very same gensym appears in multiple places.---GLS]

As a special case, the \emph{typespec} can also be the symbol \cd{:no-error} in
the last clause.  If it is, it designates a clause that will take control if the
\emph{expression} returns normally. In that case, a completely general
lambda-list may follow the symbol \cd{:no-error}, and the arguments to which the
lambda-list parameters are bound are like those for \cdf{multiple-value-call} on
the return value of the \emph{expression}.  For example,
\begin{lisp}
(handler-case \emph{expression} \\*
~~(\emph{type\SU{1}} (\emph{var\SU{1}}) . \emph{body\SU{1}}) \\*
~~(\emph{type\SU{2}} (\emph{var\SU{2}}) . \emph{body\SU{2}}) \\*
~~... \\*
~~(\emph{type\SU{n}} (\emph{var\SU{n}}) . \emph{body\SU{n}}) \\*
~~(:no-error (\emph{nvar\SU{1}} \emph{nvar\SU{2}} ... \emph{nvar\SU{m}}) . \emph{nbody}))
\end{lisp}
is approximately equivalent to
\begin{lisp}
(block \#1=\#:error-return \\*
~~(multiple-value-call \#'(lambda (\emph{nvar\SU{1}} \emph{nvar\SU{2}} ... \emph{nvar\SU{m}}) . \emph{nbody}) \\*
~~~~(block \#2=\#:normal-return \\*
~~~~~~(return-from \#1\# \\*
~~~~~~~~(handler-case (return-from \#2\# \emph{expression}) \\*
~~~~~~~~~~(\emph{type\SU{1}} (\emph{var\SU{1}}) . \emph{body\SU{1}}) \\*
~~~~~~~~~~(\emph{type\SU{2}} (\emph{var\SU{2}}) . \emph{body\SU{2}}) \\*
~~~~~~~~~~... \\*
~~~~~~~~~~(\emph{type\SU{n}} (\emph{var\SU{n}}) . \emph{body\SU{n}}))))))
\end{lisp}

Examples of the use of \cdf{handler-case}:
\begin{lisp}
(handler-case (/ x y) \\*
~~(division-by-zero () nil)) \\
 \\
(handler-case (open *the-file* :direction :input) \\*
~~(file-error (condition) (format t "{\Xtilde}\&Fooey: {\Xtilde}A{\Xtilde}\%" condition))) \\
 \\
(handler-case (some-user-function) \\*
~~(file-error (condition) condition) \\*
~~(division-by-zero () 0) \\*
~~((or unbound-variable undefined-function) () 'unbound)) \\
 \\
(handler-case (intern x y) \\*
~~(error (condition) condition) \\*
~~(:no-error (symbol status) \\*
~~~~(declare (ignore symbol)) \\*
~~~~status))
\end{lisp}
\end{defmac}

\begin{defmac}
ignore-errors {form}*

Executes its body in a context that handles conditions of type \cdf{error} by
returning control to this form. If no such condition is signaled, any values
returned by the last form are returned by \cdf{ignore-errors}. Otherwise, two
values are returned: \cdf{nil} and the \cdf{error} condition that was signaled.

\cdf{ignore-errors} could be defined by
\begin{lisp}
(defmacro ignore-errors (\&body forms) \\*
~~{\Xbq}(handler-case (progn ,{\Xatsign}forms) \\*
~~~~~(error (c) (values nil c))))
\end{lisp}
\end{defmac}

\begin{defmac}
handler-bind ({(typespec handler)}*) {form}*

Executes body in a dynamic context where the given handler bindings are in
effect.  Each \emph{typespec} may be any type specifier.  Each \emph{handler}
form should evaluate to a function to be used to handle conditions of the given
type(s) during execution of the \emph{form\/}s. This function should take a
single argument, the condition being signaled.

If more than one binding is specified, the bindings are searched sequentially
from top to bottom in search of a match (by visual analogy with
\cdf{typecase}). If an appropriate \emph{typespec} is found, the associated
handler is run in a context where none of the handler bindings are visible (to
avoid recursive errors). For example, in the case of
\begin{lisp}
(handler-bind ((unbound-variable \#'(lambda ...)) \\*
~~~~~~~~~~~~~~~(error \#'(lambda ...))) \\*
~~...)
\end{lisp}
if an unbound variable error is signaled in the body (and not handled by an
intervening handler), the first function will be called. If any other kind of
error is signaled, the second function will be called.  In either case, neither
handler will be active while executing the code in the associated function.
\end{defmac}

\subsection{Defining Conditions}

[The contents of this section are still a subject of some debate within X3J13.
The reader may wish to take this section with a grain of salt, two aspirin
tablets, and call a hacker in the morning.---GLS]

\begin{defmac}
define-condition name ({parent-type}*)
                 [({slot-specifier}*) {option}*]

Defines a new condition type called \emph{name}, which is a
subtype of each given \emph{parent-type}.  Except as otherwise
noted, the arguments are not evaluated.

Objects of this condition type will have all of the indicated \emph{slot\/}s,
plus any additional slots inherited from the parent types (its superclasses).
If the \emph{slot\/}s list is omitted, the empty list is assumed.

A \emph{slot} must have the form
\begin{tabbing}
\emph{slot-specifier\/} ::= \emph{slot-name\/} {\Mor} (\emph{slot-name\/}  $\lbrack\!\lbrack\downarrow\!\emph{slot-option}\,\rbrack\!\rbrack$)
\end{tabbing}
For the syntax of a \emph{slot-option}, see \cdf{defclass}.
The slots of a condition object are normal CLOS slots.
Note that \cdf{with-slots} may be used instead of accessor functions to access slots of a
condition object.

\cdf{make-condition} will accept keywords (in the keyword package) with the
print name of any of the designated slots, and will initialize the corresponding
slots in conditions it creates.

Accessors are created according to the same rules as used by \cdf{defclass}.

The valid \emph{options} are as follows:

\begin{flushdesc}
\item[\cd{(:documentation \emph{doc-string})}]

  The \emph{doc-string} should be either \cdf{nil} or a string that describes
  the purpose of the condition type. If this option is omitted, \cdf{nil} is
  assumed.  Calling \cd{(documentation '\emph{name} 'type)} will retrieve this
  information.

\item[\cd{(:report \emph{exp})}]

  If \emph{exp} is not a literal string, it must be a suitable argument to the
  \cdf{function} special operator. The expression \cd{(function~\emph{exp})}
  will be evaluated in the current lexical environment. It should produce a
  function of two arguments, a condition and a stream, that prints on the stream
  a description of the condition. This function is called whenever the condition
  is printed while \cdf{*print-escape*} is \cdf{nil}.

  If \emph{exp} is a literal string, it is shorthand for
  \begin{lisp}
    (lambda (c s) \\*
    ~~(declare (ignore c)) \\*
    ~~(write-string \emph{exp} s))
  \end{lisp}
  [That is, a function is provided that will simply write the given
  string literally to the stream, regardless of the particular condition object
  supplied.---GLS]

  The \cd{:report} option is processed \emph{after} the new condition type has
  been defined, so use of the slot accessors within the report function is
  permitted.  If this option is not specified, information about how to report
  this type of condition will be inherited from the \emph{parent-type}.
\end{flushdesc}

[X3J13 voted in March 1989 \issue{ZLOS-CONDITIONS} to integrate the
Condition System and the Object System.
In the original Condition System proposal, \cdf{define-condition}
allowed only one \emph{parent-type} (the inheritance structure was a simple
hierarchy).
Slot descriptions were much simpler, even simpler than those for \cdf{defstruct}:
\begin{tabbing}
\emph{slot} ::= \emph{slot-name} {\Mor} (\emph{slot-name}) {\Mor} (\emph{slot-name} \emph{default-value})
\end{tabbing}
Similarly, \cdf{define-condition} allowed
a \cd{:conc-name} option similar to that of \cdf{defstruct}:
\begin{flushdesc}
\item[\cd{(:conc-name \emph{symbol-or-string})}]

     \textbf{Not now part of Common Lisp.}
     As with \cdf{defstruct}, this sets up automatic prefixing of the names 
     of slot accessors. Also as in \cdf{defstruct}, the default behavior 
     is to use the name of the new type, \emph{name}, followed by a hyphen.
     (Generated names are interned in the package that is current at the time that the 
     \cdf{define-condition} is processed).
\end{flushdesc}
One consequence of the vote was to make \cdf{define-condition} slot descriptions
like those of \cdf{defclass}.---GLS]

Here are some examples of the use of \cdf{define-condition}.

The following form defines a condition of type \cd{peg/hole-mismatch} that
inherits from a condition type called \cdf{blocks-world-error}:
\begin{lisp}
(define-condition peg/hole-mismatch (blocks-world-error) \\*
~~~~~~~~~~~~~~~~~~(peg-shape hole-shape) \\*
~~(:report \\
~~~~(lambda (condition stream) \\*
~~~~~~(with-slots (peg-shape hole-shape) condition \\*
~~~~~~~~(format stream "A {\Xtilde}A peg cannot go in a {\Xtilde}A hole." \\*
~~~~~~~~~~~~~~~~peg-shape hole-shape))))
\end{lisp}
The new type has slots \cdf{peg-shape} and \cdf{hole-shape}, so
\cdf{make-condition} will accept \cd{:peg-shape} and \cd{:hole-shape}
keywords. The \cdf{with-slots} macro may be used to access the \cdf{peg-shape}
and \cdf{hole-shape} slots, as illustrated in the \cd{:report} information.

Here is another example. This defines a condition called \cdf{machine-error}
that inherits from \cdf{error}:
\begin{lisp}
(define-condition machine-error (error) \\*
~~~~~~~~~~~~~~~~~~((machine-name \\*
~~~~~~~~~~~~~~~~~~~~:reader machine-error-machine-name)) \\
~~(:report (lambda (condition stream) \\*
~~~~~~~~~~~~~(format stream "There is a problem with {\Xtilde}A." \\*
~~~~~~~~~~~~~~~~~~~~~(machine-error-machine-name condition)))))
\end{lisp}
Building on this definition, we can define a new error condition that is a
subtype of \cdf{machine-error} for use when machines are not available:
\begin{lisp}
(define-condition machine-not-available-error (machine-error) () \\*
~~(:report (lambda (condition stream) \\*
~~~~~~~~~~~~~(format stream "The machine {\Xtilde}A is not available." \\*
~~~~~~~~~~~~~~~~~~~~~(machine-error-machine-name condition)))))
\end{lisp}
We may now define a still more specific condition, built upon
\cd{machine-not-available-error}, that provides a default for \cdf{machine-name}
but does not provide any new slots or report information. It just gives the
\cdf{machine-name} slot a default initialization:
\begin{lisp}
(define-condition my-favorite-machine-not-available-error \\*
~~~~~~~~~~~~~~~~~~(machine-not-available-error) \\*
~~~~~~~~~~~~~~~~~~((machine-name :initform "MC.LCS.MIT.EDU")))
\end{lisp}
Note that since no \cd{:report} clause was given, the information inherited from
\cdf{machine-not-available-error} will be used to report this type of condition.
\end{defmac}

\subsection{Creating Conditions}

The function \cdf{make-condition} is the basic means for
creating condition objects.

\begin{defun}[Function]
make-condition type &rest slot-initializations

Constructs a condition object of the given \emph{type} using
\emph{slot-initializations} as a specification of the initial value of the
slots. The newly created condition is returned.

The \emph{slot-initializations} are alternating keyword/value pairs.  For
example:
\begin{lisp}
(make-condition 'peg/hole-mismatch \\*
~~~~~~~~~~~~~~~~:peg-shape 'square :hole-shape 'round)
\end{lisp}
\end{defun}

\subsection{Establishing Restarts}

The lowest-level form that creates restart points is called \cdf{restart-bind}.
The \cdf{restart-case} macro is an abstraction that addresses many common needs
for \cdf{restart-bind} while offering a more palatable syntax. See also
\cdf{with-simple-restart}.  The function that transfers control to a restart
point established by one of these macros is called \cdf{invoke-restart}.

All restarts have dynamic extent; a restart does not survive execution of the
form that establishes it.

\begin{defmac}
with-simple-restart (name format-string {format-argument}*)
                    {form}*

This is shorthand for one of the most common uses of \cdf{restart-case}.

If the restart designated by \emph{name} is not invoked while executing the
\emph{form\/}s, all values returned by the last \emph{form} are returned. If
that restart is invoked, control is transferred to the \cdf{with-simple-restart}
form, which immediately returns the two values \cdf{nil} and \cdf{t}.

The \emph{name} may be \cdf{nil}, in which case an anonymous restart is
established.

\cdf{with-simple-restart} could be defined by
\begin{lisp}
(defmacro with-simple-restart ((restart-name format-string \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\&rest format-arguments) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\&body forms) \\
~~{\Xbq}(restart-case (progn ,{\Xatsign}forms) \\*
~~~~~(,restart-name () \\*
~~~~~~~:report \\*
~~~~~~~~~(lambda (stream) \\*
~~~~~~~~~~~(format stream format-string ,{\Xatsign}format-arguments)) \\*
~~~~~~~(values nil t))))
\end{lisp}

Here is an example of the use of \cdf{with-simple-restart}.
\begin{lisp}
Lisp> (defun read-eval-print-loop (level) \\*
~~~~~~~~(with-simple-restart \\*
~~~~~~~~~~~~(abort "Exit command level {\Xtilde}D." level) \\*
~~~~~~~~~~(loop \\*
~~~~~~~~~~~~(with-simple-restart \\*
~~~~~~~~~~~~~~~~(abort "Return to command level {\Xtilde}D." level) \\*
~~~~~~~~~~~~~~(let ((form (prog2 (fresh-line) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(read) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(fresh-line)))) \\*
~~~~~~~~~~~~~~~~(prin1 (eval form))))))) \\*
~\EV\ READ-EVAL-PRINT-LOOP \\
Lisp> (read-eval-print-loop 1) \\*
(+ 'a 3) \\
Error: The argument, A, to the function + was of the wrong type. \\*
~~~~~~~The function expected a number. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify a value to use this time. \\*
~2: Return to command level 1. \\*
~3: Exit command level 1. \\*
~4: Return to Lisp Toplevel. \\*
Debug> 
\end{lisp}

\beforenoterule
\begin{sideremark}
Some readers may wonder what ought to be done by the ``abort'' key (or whatever
the implementation's interrupt key is---Control-C or Control-G, for
example). Such interrupts, whether synchronous or asynchronous in nature, are
beyond the scope of this chapter and indeed are not currently addressed by
Common Lisp at all. This may be a topic worth standardizing under separate
cover. Here is some speculation about some possible things that might happen.

An implementation might simply call \cdf{abort} or \cdf{break} directly without
signaling any condition.

Another implementation might signal some condition related to the fact that a
key had been pressed rather than to the action that should be taken. This is one
way to allow user customization.  Perhaps there would be an
implementation-dependent \cdf{keyboard-interrupt} condition type with a slot
containing the key that was pressed---or perhaps there would be such a condition
type, but rather than its having slots, different subtypes of that type with
names like \cdf{keyboard-abort}, \cdf{keyboard-break}, and so on might be
signaled. That implementation would then document the action it would take if
user programs failed to handle the condition, and perhaps ways for user programs
to usefully dismiss the interrupt.
\end{sideremark}
\betweennoterule
\begin{implementation}
Implementors are encouraged to make sure that there is always a restart named
\cdf{abort} around any user code so that user code  can call \cdf{abort} at any
time and expect something reasonable to happen; exactly what the reasonable
thing is may vary somewhat. Typically, in an interactive program, invoking
\cdf{abort} should return the user to top level, though in some batch or
multi-processing situations killing the running process might be more
appropriate.
\end{implementation}
\afternoterule
\end{defmac}

\begin{defmac}
restart-case expression {(case-name arglist
                         {keyword value}*
                         {form}*)}*

The \emph{expression} is evaluated in a dynamic context where the clauses have
special meanings as points to which control may be transferred. If the
\emph{expression} finishes executing and returns any values, all such values are
simply returned by the \cdf{restart-case} form. While the \emph{expression} is
running, any code may transfer control to one of the clauses (see
\cdf{invoke-restart}). If a transfer occurs, the \emph{form\/}s in the body of
that clause will be evaluated and any values returned by the last such
\emph{form} will be returned by the \cdf{restart-case} form.

As a special case, if the \emph{expression} is a list whose \emph{car} is
\cdf{signal}, \cdf{error}, \cdf{cerror}, or \cdf{warn}, then
\cdf{with-condition-restarts} is implicitly used to associate the restarts with
the condition to be signaled.  For example,
\begin{lisp}
(restart-case (signal weird-error) \\*
~~(become-confused ...) \\*
~~(rewind-line-printer ...) \\*
~~(halt-and-catch-fire ...))
\end{lisp}
is equivalent to
\begin{lisp}
(restart-case (with-condition-restarts \\*
~~~~~~~~~~~~~~~~weird-error  \\*
~~~~~~~~~~~~~~~~(list (find-restart 'become-confused)  \\*
~~~~~~~~~~~~~~~~~~~~~~(find-restart 'rewind-line-printer) \\*
~~~~~~~~~~~~~~~~~~~~~~(find-restart 'halt-and-catch-fire)) \\*
~~~~~~~~~~~~~~~~(signal weird-error)) \\
~~(become-confused ...) \\*
~~(rewind-line-printer ...) \\*
~~(halt-and-catch-fire ...))
\end{lisp}

If there are no \emph{form\/}s in a selected clause, \cdf{restart-case} returns
\cdf{nil}.

The \emph{case-name} may be \cdf{nil} or a symbol naming this restart.

It is possible to have more than one clause use the same \emph{case-name}.  In
this case, the first clause with that name will be found by
\cdf{find-restart}. The other clauses are accessible using
\cdf{compute-restarts}.  [In this respect, \cdf{restart-case} is rather
different from \cdf{case}!---GLS]

Each \emph{arglist} is a normal lambda-list containing parameters to be bound
during the execution of its corresponding \emph{form\/}s. These parameters are
used to pass any necessary data from a call to \cdf{invoke-restart} to the
\cdf{restart-case} clause.

By default, \cdf{invoke-restart-interactively} will pass no arguments and all
parameters must be optional in order to accommodate interactive
restarting. However, the parameters need not be optional if the
\cd{:interactive} keyword has been used to inform
\cdf{invoke-restart-interactively} about how to compute a proper argument list.

The valid \emph{keyword value} pairs are the following:
\begin{flushdesc}
\item[\cd{:test \emph{fn}}]

  The \emph{fn} must be a suitable argument for the \cdf{function} special
  operator. The expression \cd{(function~\emph{fn})} will be evaluated in the
  current lexical environment. It should produce a function of one argument, a
  condition.  If this function returns \cdf{nil} when given some condition,
  functions such as \cdf{find-restart}, \cdf{compute-restart}, and
  \cdf{invoke-restart} will not consider this restart when searching for
  restarts associated with that condition.  If this pair is not supplied, it is
  as if
\begin{lisp}
  (lambda (c) (declare (ignore c)) t)
\end{lisp}
 were used for the \emph{fn}.

\item[\cd{:interactive \emph{fn}}]

  The \emph{fn} must be a suitable argument for the \cdf{function} special
  operator. The expression \cd{(function~\emph{fn})} will be evaluated in the
  current lexical environment. It should produce a function of no arguments that
  returns arguments to be used by \cdf{invoke-restart-interactively} when
  invoking this function. This function will be called in the dynamic
  environment available prior to any restart attempt. It may interact with the
  user on the stream in \cdf{*query-io*}.

  If a restart is invoked interactively but no \cd{:interactive} option was
  supplied, the argument list used in the invocation is the empty list.

\item[\cd{:report \emph{exp}}]

  If \emph{exp} is not a literal string, it must be a suitable argument to the
  \cdf{function} special operator. The expression \cd{(function~\emph{exp})}
  will be evaluated in the current lexical environment. It should produce a
  function of one argument, a stream, that prints on the stream a description of
  the restart. This function is called whenever the restart is printed while
  \cdf{*print-escape*} is \cdf{nil}.

  If \emph{exp} is a literal string, it is shorthand for
  \begin{lisp}
    (lambda (s) (write-string \emph{exp} s))
  \end{lisp}
  [That is, a function is provided that will simply write the given
  string literally to the stream.---GLS]

  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 \cdf{*print-escape*} is \cdf{nil}, the printer will use the report
  information for a restart. For example, a debugger might announce the action
  of typing ``\cd{:continue}'' by executing the equivalent of
  \begin{lisp}
    (format *debug-io* "{\Xtilde}\&{\Xtilde}S -- {\Xtilde}A{\Xtilde}\%" ':continue some-restart)
  \end{lisp}
  which might then display as something like
  \begin{lisp}
    :CONTINUE -- Return to command level.
  \end{lisp}

  It is an error if an unnamed restart is used and no report information
  is provided.

\beforenoterule
\begin{rationale}
Unnamed restarts are required to have report information on
the grounds that they are generally only useful interactively, and an
interactive option that has no description is of little value.
\end{rationale}
\betweennoterule
\begin{implementation}
Implementations are encouraged to warn about this error
at compilation time.

At run time, 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, and so on), it is suggested that the
debugger print some indication of such problems when they occur, but not
actually signal errors.
\end{implementation}
\afternoterule

\end{flushdesc}

Note that 
\begin{lisp}
(restart-case \emph{expression} \\*
~~(\emph{name\SU{1}} \emph{arglist\SU{1}} \emph{options\SU{1}} . \emph{body\SU{1}}) \\*
~~(\emph{name\SU{2}} \emph{arglist\SU{2}} \emph{options\SU{2}} . \emph{body\SU{2}}) \\*
~~...)
\end{lisp}
is essentially equivalent to
\begin{lisp}
(block \#1=\#:block-1 \\*
~~(let ((\#2=\#:var-2 nil)) \\*
~~~~(tagbody \\*
~~~~~~(restart-bind ((\emph{name\SU{1}} \=\#'(lambda (\&rest temp) \\*
\>~~~~(setq \#2\# temp) \\*
\>~~~~(go \#3=\#:tag-3)) \\*
\>\textrm{$\langle$slightly transformed \emph{options\SU{1}}$\rangle$}) \\
~~~~~~~~~~~~~~~~~~~~~(\emph{name\SU{2}} \=\#'(lambda (\&rest temp) \\*
\>~~~~(setq \#2\# temp) \\*
\>~~~~(go \#4=\#:tag-4)) \\*
\>\textrm{$\langle$slightly transformed \emph{options\SU{2}}$\rangle$}) \\*
~~~~~~~~~~~~~~~~~~~~~...) \\*
~~~~~~~~(return-from \#1\# expression)) \\
~~~~~~\#3\# (return-from \#1\# \\*
~~~~~~~~~~~~~~~~(apply \#'(lambda \emph{arglist\SU{1}} . \emph{body\SU{1}}) \#2\#)) \\
~~~~~~\#4\# (return-from \#1\# \\*
~~~~~~~~~~~~~~~~(apply \#'(lambda \emph{arglist\SU{2}} . \emph{body\SU{2}}) \#2\#)) \\*
~~~~~~...)))
\end{lisp}
[Note the use of ``gensyms'' such as \cd{\#:block-1} as block names,
variables, and \cdf{tagbody} tags in this example,
and the use of \cd{\#\emph{n}=} and \cd{\#\emph{n}\#} read-macro syntax
to indicate that the very same gensym appears in multiple places.---GLS]


Here are some examples of the use of \cdf{restart-case}.
\begin{lisp}
(loop \\*
~~(restart-case (return (apply function some-args)) \\*
~~~~(new-function (new-function) \\*
~~~~~~~~:report "Use a different function." \\*
~~~~~~~~:interactive \\*
~~~~~~~~~~(lambda () \\*
~~~~~~~~~~~~(list (prompt-for 'function "Function: "))) \\*
~~~~~~(setq function new-function)))) \\
 \\
(loop \\*
~~(restart-case (return (apply function some-args)) \\*
~~~~(nil (new-function) \\*
~~~~~~~~:report "Use a different function." \\*
~~~~~~~~:interactive \\*
~~~~~~~~~~(lambda () \\*
~~~~~~~~~~~~(list (prompt-for 'function "Function: "))) \\*
~~~~~~(setq function new-function)))) \\
 \\
(restart-case (a-command-loop) \\*
~~(return-from-command-level () \\*
~~~~~~:report \\*
~~~~~~~~(lambda (s)~~~~~;\textrm{Argument \cdf{s} is a stream} \\*
~~~~~~~~~~(format s "Return from command level {\Xtilde}D." level)) \\*
~~~~nil)) \\
 \\
(loop  \\*
~~(restart-case (another-random-computation) \\*
~~~~(continue () nil)))
\end{lisp}
The first and second examples are equivalent from the point of view of someone
using the interactive debugger, but they differ in one important aspect for
non-interactive handling. If a handler ``knows about'' named restarts, as in,
for example,
\begin{lisp}
(when (find-restart 'new-function) \\*
~~(invoke-restart 'new-function the-replacement))
\end{lisp}
then only the first example, and not the second, will have control transferred
to its correction clause, since only the first example uses a restart named
\cdf{new-function}.

Here is a more complete example:
\begin{lisp}
(let ((my-food 'milk) \\*
~~~~~~(my-color 'greenish-blue)) \\*
~~(do () \\*
~~~~~~((not (bad-food-color-p my-food my-color))) \\*
~~~~(restart-case (error 'bad-food-color \\*
~~~~~~~~~~~~~~~~~~~~~~~~~:food my-food :color my-color) \\*
~~~~~~(use-food (new-food) \\*
~~~~~~~~~~:report "Use another food." \\*
~~~~~~~~(setq my-food new-food)) \\
~~~~~~(use-color (new-color) \\*
~~~~~~~~~~:report "Use another color." \\*
~~~~~~~~(setq my-color new-color)))) \\*
~~;; We won't get to here until MY-FOOD \\*
~~;; and MY-COLOR are compatible. \\*
~~(list my-food my-color))
\end{lisp}
Assuming that \cdf{use-food} and \cdf{use-color} have been defined as
\begin{lisp}
(defun use-food (new-food) \\*
~~(invoke-restart 'use-food new-food)) \\
\\
(defun use-color (new-color) \\*
~~(invoke-restart 'use-color new-color))
\end{lisp}
a handler can then restart from the error in either of two ways.
It may correct the color or correct the food. For example:
\begin{lisp}
\#'(lambda (c) ... (use-color 'white) ...)~~~;\textrm{Corrects \cdf{color}} \\
\\
\#'(lambda (c) ... (use-food 'cheese) ...)~~~;\textrm{Corrects \cdf{food}}
\end{lisp}

Here is an example using \cdf{handler-bind} and \cdf{restart-case} that refers to a
condition type \cdf{foo-error}, presumably defined elsewhere:
\begin{lisp}
(handler-bind ((foo-error \#'(lambda (ignore) (use-value 7)))) \\*
~~(restart-case (error 'foo-error) \\*
~~~~(use-value (x) (* x x)))) \\*
~\EV\ 49
\end{lisp}
\end{defmac}


\begin{defmac}
restart-bind ({(name function {keyword value}*)}*) {form}*

Executes a body of forms in a dynamic context where the given restart bindings
are in effect.

Each \emph{name} may be \cdf{nil} to indicate an anonymous restart, or some
other symbol to indicate a named restart.

Each \emph{function} is a form that should evaluate to a function to be used to
perform the restart.  If invoked, this function may either perform a non-local
transfer of control or it may return normally. The function may take whatever
arguments the programmer feels are appropriate; it will be invoked only if
\cdf{invoke-restart} is used from a program, or if a user interactively asks the
debugger to invoke it. In the case of interactive invocation, the
\cd{:interactive-function} option is used.

The valid \emph{keyword value} pairs are as follows:
\begin{flushdesc}
\item[\cd{:test-function \emph{form}}]

  The \emph{form} will be evaluated in the current lexical environment and
  should return a function of one argument, a condition.  If this function
  returns \cdf{nil} when given some condition, functions such as
  \cdf{find-restart}, \cdf{compute-restart}, and \cdf{invoke-restart} will not
  consider this restart when searching for restarts associated with that
  condition.  If this pair is not supplied, it is as if
  \begin{lisp}
    \#'(lambda (c) (declare (ignore c)) t)
  \end{lisp}
  were used for the \emph{form}.
  
\item[\cd{:interactive-function \emph{form}}]

  The \emph{form} will be evaluated in the current lexical environment and
  should return a function of no arguments that constructs a list of arguments
  to be used by \cdf{invoke-restart-interactively} when invoking this
  restart. The function may prompt interactively using \cdf{*query-io*} if
  necessary.

\item[\cd{:report-function \emph{form}}]

  The \emph{form} will be evaluated in the current lexical environment and
  should return a function of one argument, a stream, that prints on the stream
  a summary of the action this restart will take. This function is called
  whenever the restart is printed while \cdf{*print-escape*} is \cdf{nil}.
\end{flushdesc}
\end{defmac}

\begin{defmac}
with-condition-restarts condition-form restarts-form
  {declaration}* {form}*

The value of \emph{condition-form} should be a condition \emph{C} and the value
of \emph{restarts-form} should be a list of restarts \cd{(\emph{R1} \emph{R2}
...)}.  The \emph{form\/}s of the body are evaluated as an implicit \cdf{progn}.
While in the dynamic context of the body, an attempt to find a restart
associated with a particular condition $C'$ will consider the restarts
\emph{R1}, \emph{R2}, $\ldots$ if $C'$ is \cdf{eq} to \emph{C}.

 Usually this macro is not used explicitly in code, because \cdf{restart-case}
handles most of the common uses in a way that is syntactically more concise.

[The X3J13 vote \issue{CONDITION-RESTARTS} left it unclear whether \cdf{with-condition-restarts}
permits declarations to appear at the heads of its body.
I believe that was the intent, but this is only my interpretation.---GLS]
\end{defmac}

\subsection{Finding and Manipulating Restarts}

The following functions determine what restarts are
active and invoke restarts.

\begin{defun}[Function]
compute-restarts &optional condition

Uses the dynamic state of the program to compute a list of the restarts that are
currently active. See \cdf{restart-bind}.

If \emph{condition} is \cdf{nil} or not supplied, all outstanding restarts
are returned.
If \emph{condition} is not \cdf{nil}, only restarts associated
with that condition are returned.

Each restart represents a 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. Implementations are free to implement these objects in whatever manner
is most convenient; the objects need have only dynamic extent (relative to the
scope of the binding form that instantiates them).

The list that results from a call to \cdf{compute-restarts} is ordered so that
the inner (that is, more recently established) restarts are nearer the head of
the list.

Note, too, that \cdf{compute-restarts} returns all valid restarts, including
anonymous ones, even if some of them have the same name as others and would
therefore not be found by \cdf{find-restart} when given a symbol argument.

Implementations are permitted, but not required, to return different (that is,
non-\cdf{eq}) lists from repeated calls to \cdf{compute-restarts} while in the
same dynamic environment. It is an error to modify the list that is returned by
\cdf{compute-restarts}.
\end{defun}


\begin{defun}[Function]
restart-name restart

Returns the name of the given \emph{restart}, or \cdf{nil} if it is not named.
\end{defun}

\begin{defun}[Function]
find-restart restart-identifier &optional condition

Searches for a particular restart in the current dynamic environment.

If \emph{condition} is \cdf{nil} or not supplied, all outstanding restarts
are considered.
If \emph{condition} is not \cdf{nil}, only restarts associated
with that condition are considered.

If the \emph{restart-identifier} is a non-\cdf{nil} symbol, then the innermost
(that is, most recently established) restart with that name is returned;
\cdf{nil} is returned if no such restart is found.

If \emph{restart-identifier} is a restart object, then it is simply returned,
unless it is not currently active, in which case \cdf{nil} is returned.

Although anonymous restarts have a name of \cdf{nil}, it is an error for the
symbol \cdf{nil} to be given as the \emph{restart-identifier}.  Applications
that would seem to require this should be rewritten to make appropriate use of
\cdf{compute-restarts} instead.
\end{defun}

\begin{defun}[Function]
invoke-restart restart-identifier &rest arguments

Calls the function associated with the given \emph{restart-identifier}, passing
any given \emph{arguments}. The \emph{restart-identifier} must be a restart or
the non-null name of a restart that is valid in the current dynamic context. If
the argument is not valid, an error of type \cdf{control-error} will be
signaled.

\beforenoterule
\begin{implementation} 
Restart functions call this function, not vice versa.
\end{implementation} 
\afternoterule
\end{defun}

\begin{defun}[Function]
invoke-restart-interactively restart-identifier

Calls the function associated with the given \emph{restart-identifier},
prompting for any necessary arguments. The \emph{restart-identifier} must be a
restart or the non-null name of a restart that is valid in the current dynamic
context. If the argument is not valid, an error of type \cdf{control-error} will
be signaled.

The function \cdf{invoke-restart-interactively} will prompt for arguments by
executing the code provided in the \cd{:interactive} keyword to
\cdf{restart-case} or  \cd{:interactive-function} keyword to \cdf{restart-bind}.

If no \cd{:interactive} or \cd{:interactive-function} option has been supplied
in the corresponding \cdf{restart-case} or \cdf{restart-bind}, then it is an
error if the restart takes required arguments. If the arguments are optional, an
empty argument list will be used in this case.

Once \cdf{invoke-restart-interactively} has calculated the arguments, it simply
performs \cd{(apply~\#'invoke-restart \emph{restart-identifier}
\emph{arguments})}.

\cdf{invoke-restart-interactively} is used internally by the debugger and may
also be useful in implementing other portable, interactive debugging tools.
\end{defun}


\subsection{Warnings}
\label{WARNING-CONDITIONS}

Warnings are a subclass of errors that are conventionally regarded as ``mild.''

\begin{defun}[Function]
warn datum &rest arguments

Warns about a situation, by signaling a condition of type \cdf{warning}.

If \emph{datum} is a condition, then that condition is used directly.  In this
case, if the condition is not of type \cdf{warning} or arguments is
non-\cdf{nil}, an error of type \cdf{type-error} is signaled.

If \emph{datum} is a condition type (a class or class name), then the condition
used is effectively the result of \cd{(apply \#'make-condition \emph{datum}
\emph{arguments})}. This result must be of type \cdf{warning} or an error of
type \cdf{type-error} is signaled.

If \emph{datum} is a string, then the condition used is effectively the result
of
\begin{lisp}
(make-condition 'simple-error \\*
~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
~~~~~~~~~~~~~~~~:format-arguments \emph{arguments})
\end{lisp}

The precise mechanism for warning is as follows.
\begin{enumerate}

\item The warning condition is signaled.

  While the \cdf{warning} condition is being signaled, the \cdf{muffle-warning}
  restart is established for use by a handler to bypass further action by
  \cdf{warn} (that is, to cause \cdf{warn} to immediately return \cdf{nil}).

  As part of the signaling process, if \cd{(typep \emph{condition}
    *break-on-signals*)} is true, then a \cdf{break} will occur prior to
  beginning the signaling process.

\item If no handlers for the warning condition are found, or if all such
  handlers decline, then the condition will be reported to \cdf{*error-output*}
  by the \cdf{warn} function (with possible implementation-specific extra output
  such as motion to a fresh line before or after the display of the warning, or
  supplying some introductory text mentioning the name of the function that
  called \cdf{warn} or the fact that this is a warning).

\item The value returned by \cdf{warn} (if it returns) is \cdf{nil}.
\end{enumerate}
\end{defun}

\subsection{Restart Functions}

Common Lisp has the following restart functions built in.

\begin{defun}[Function]
abort &optional condition

This function transfers control to the restart named \cdf{abort}. If no such
restart exists, \cdf{abort} signals an error of type \cdf{control-error}.

If \emph{condition} is \cdf{nil} or not supplied, all outstanding restarts are
considered.  If \emph{condition} is not \cdf{nil}, only restarts associated with
that condition are considered.

The purpose of the \cdf{abort} restart is generally to allow control to return
to the innermost ``command level.''
\end{defun}

\begin{defun}[Function]
continue &optional condition

This function transfers control to the restart named \cdf{continue}. If no such
restart exists, \cdf{continue} returns \cdf{nil}.

If \emph{condition} is \cdf{nil} or not supplied, all outstanding restarts are
considered.  If \emph{condition} is not \cdf{nil}, only restarts associated with
that condition are considered.

The \cdf{continue} restart is generally part of simple protocols where there is
a single ``obvious'' way to continue, as with \cdf{break} and \cdf{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 better suits the particular application.
\end{defun}

\begin{defun}[Function]
muffle-warning &optional condition

This function transfers control to the restart named \cdf{muffle-warning}.  If
no such restart exists, \cdf{muffle-warning} signals an error of type
\cdf{control-error}.

If \emph{condition} is \cdf{nil} or not supplied, all outstanding restarts are
considered.  If \emph{condition} is not \cdf{nil}, only restarts associated with
that condition are considered.

\cdf{warn} sets up this restart so that handlers of \cdf{warning} conditions
have a way to tell \cdf{warn} that a \cdf{warning} has already been dealt with
and that no further action is warranted.
\end{defun}

\begin{defun}[Function]
store-value value &optional condition

This function transfers control (and one value) to the restart named
\cdf{store-value}. If no such restart exists, \cdf{store-value} returns
\cdf{nil}.

If \emph{condition} is \cdf{nil} or not supplied, all outstanding restarts are
considered.  If \emph{condition} is not \cdf{nil}, only restarts associated with
that condition are considered.

The \cdf{store-value} restart is generally used by handlers trying to recover
from errors of types such as \cdf{cell-error} or \cdf{type-error}, where the
handler may wish to supply a replacement datum to be stored permanently.
\end{defun}

\begin{defun}[Function]
use-value value &optional condition

This function transfers control (and one value) to the restart named
\cdf{use-value}. If no such restart exists, \cdf{use-value} returns \cdf{nil}.

If \emph{condition} is \cdf{nil} or not supplied, all outstanding restarts are
considered.  If \emph{condition} is not \cdf{nil}, only restarts associated with
that condition are considered.

The \cdf{use-value} restart is generally used by handlers trying to recover from
errors of types such as \cdf{cell-error}, where the handler may wish to supply a
replacement datum for one-time use.
\end{defun}

\subsection{Debugging Utilities}
\label{DEBUGGING-UTILITIES}

Common Lisp does not specify exactly what a debugger is or does,
but it does provide certain means for indicating intent to transfer control
to a supervisory or debugging facility.

\begin{defun}[Function]
break &optional format-string &rest format-arguments

The function \cdf{break} prints the message described by the
\emph{format-string} and \emph{format-arguments} and then goes directly into the
debugger without allowing any possibility of interception by programmed
error-handling facilities.

If no \emph{format-string} is supplied, a suitable default will be generated.

If continued, \cdf{break} returns \cdf{nil}.

Note that \cdf{break} is presumed to be used as a way of inserting temporary
debugging ``breakpoints'' in a program, not as a way of signaling errors; it is
expected that continuing from a \cdf{break} will not trigger any unusual
recovery action. For this reason, \cdf{break} does not take the additional
format control string that \cdf{cerror} takes as its first argument. This and
the lack of any possibility of interception by programmed error handling are the
only program-visible differences between \cdf{break} and \cdf{cerror}. The user
interface aspects of these functions are permitted to vary more widely; for
example, it is permissible for a read-eval-print loop to be entered by
\cdf{break} rather than by the conventional debugger.

\cdf{break} could be defined by
\begin{lisp}
(defun break (\&optional (format-string "Break") \\*
~~~~~~~~~~~~~~\&rest format-arguments) \\*
~~(with-simple-restart (continue "Return from BREAK.") \\*
~~~~(invoke-debugger \\*
~~~~~~(make-condition 'simple-condition \\*
~~~~~~~~~~~~~~~~~~~~~~:format-string format-string \\*
~~~~~~~~~~~~~~~~~~~~~~:format-arguments format-arguments))) \\*
~~nil)
\end{lisp}
\end{defun}

\begin{defun}[Function]
invoke-debugger condition

Attempts interactive handling of its argument, which must be a condition.

If the variable \cdf{*debugger-hook*} is not \cdf{nil}, it will be called as a
function on two arguments: the \emph{condition} being handled and the value of
\cdf{*debugger-hook*}.  If a hook function returns normally, the standard
debugger will be tried.

The standard debugger will never directly return. Return can occur only by a
special transfer of control, such as the use of a restart.

\beforenoterule
\begin{sideremark} 
The exact way in which the debugger interacts with users is
expected to vary considerably from system to system. For example, some systems
may use a keyboard interface, while others may use a mouse interface. Of those
systems using keyboard commands, some may use single-character commands and
others may use parsed line-at-a-time commands. The exact set of commands will
vary as well. The important properties of a debugger are that it makes
information about the error accessible and that it makes the set of apparent
restarts easily accessible.

It is desirable to have a mode where the debugger allows other features, such as
the ability to inspect data, stacks, etc. However, it may sometimes be
appropriate to have this kind of information hidden from users. Experience on
the Lisp Machines has shown that some users who are not programmers develop a
terrible phobia of debuggers. The reason for this usually may be traced to the
fact that the debugger is very foreign to them and provides an overwhelming
amount of information of interest only to programmers. With the advent of
restarts, there is a clear mechanism for the construction of ``friendly''
debuggers. Programmers can be taught how to get to the information they need for
debugging, but it should be possible to construct user interfaces to the
debugger that are natural, convenient, intelligible, and friendly even to
non-programmers.
\end{sideremark}
\afternoterule
\end{defun}

\begin{defun}[Variable]
*debugger-hook*

This variable should hold either \cdf{nil} or a function of two arguments, a
condition and the value of \cdf{*debugger-hook*}. This function may either handle
the condition (transfer control) or return normally (allowing the standard
debugger to run).

Note that, to minimize recursive errors while debugging, \cdf{*debugger-hook*} is
bound to \cdf{nil} when calling this function. When evaluating code typed in by
the user interactively, the hook function may want to bind \cdf{*debugger-hook*}
to the function that was its second argument so that recursive errors can be
handled using the same interactive facility.
\end{defun}


\section{Predefined Condition Types}        
\label{PREDEFINED-CONDITIONS-SECTION}

[The proposal for the Common Lisp Condition System introduced
a new notation for documenting types, treating them in the
same syntactic manner as functions and variables.  This notation
is used in this section but is not reflected
throughout the entire book.---GLS]

X3J13 voted in March 1989 \issue{ZLOS-CONDITIONS} to integrate
the Condition System and the Object System. 

All condition types
are CLOS classes and all condition objects are ordinary CLOS objects.

\begin{defun}[Type]
restart

This is the data type used to represent a restart.
\end{defun}

\begin{table}[t]
\caption{Condition Type Hierarchy}
\label{CONDITION-HIERARCHY-TABLE}
\begin{lisp}
condition \\
~~~~simple-condition \\
~~~~serious-condition \\
~~~~~~~~error \\
~~~~~~~~~~~~simple-error \\
~~~~~~~~~~~~arithmetic-error \\
~~~~~~~~~~~~~~~~division-by-zero \\
~~~~~~~~~~~~~~~~floating-point-overflow \\
~~~~~~~~~~~~~~~~floating-point-underflow \\
~~~~~~~~~~~~~~~~... \\
~~~~~~~~~~~~cell-error \\
~~~~~~~~~~~~~~~~unbound-variable \\
~~~~~~~~~~~~~~~~undefined-function \\
~~~~~~~~~~~~~~~~... \\
~~~~~~~~~~~~control-error \\
~~~~~~~~~~~~file-error \\
~~~~~~~~~~~~package-error \\
~~~~~~~~~~~~program-error \\
~~~~~~~~~~~~stream-error \\
~~~~~~~~~~~~~~~~end-of-file \\
~~~~~~~~~~~~~~~~... \\
~~~~~~~~~~~~type-error \\
~~~~~~~~~~~~~~~~simple-type-error \\
~~~~~~~~~~~~~~~~... \\
~~~~~~~~~~~~... \\
~~~~~~~~storage-condition \\
~~~~~~~~... \\
~~~~warning \\
~~~~~~~~simple-warning \\
~~~~~~~~... \\
~~~~...
\end{lisp}
\vfill
\end{table}

The Common Lisp condition type hierarchy is illustrated in
table~\ref{CONDITION-HIERARCHY-TABLE}.

The types that are not leaves in the hierarchy (that is, \cdf{condition},
\cdf{warning}, \cdf{storage-condition}, \cdf{error}, \cdf{arithmetic-error},
\cdf{control-error}, and so on) are provided primarily for type inclusion
purposes. Normally they would not be directly instantiated.

Implementations are permitted to support non-portable synonyms for these types,
as well as to introduce other types that are above, below, or between the types
shown in this tree as long as the indicated subtype relationships are not
violated.

The types \cdf{simple-condition}, \cdf{serious-condition}, and \cdf{warning} are
pairwise disjoint. The type \cdf{error} is also disjoint from types
\cdf{simple-condition} and \cdf{warning}.

\begin{defun}[Type]
condition

All types of conditions, whether error or non-error, must inherit from this
type.
\end{defun}

\begin{defun}[Type]
warning

All types of warnings should inherit from this type.  This is a subtype of
\cdf{condition}.
\end{defun}

\begin{defun}[Type]
serious-condition

All serious conditions (conditions serious enough to require interactive
intervention if not handled) should inherit from this type. This is a subtype of
\cdf{condition}.

This condition type is provided primarily for terminological convenience.  In
fact, signaling a condition that inherits from \cdf{serious-condition} does not
force entry into the debugger. Rather, it is conventional to use \cdf{error} (or
something built on \cdf{error}) to signal conditions that are of this type, and
to use \cdf{signal} to signal conditions that are not of this type.
\end{defun}

\begin{defun}[Type]
error

All types of error conditions inherit from this condition.  This is a subtype of
\cdf{serious-condition}.
\end{defun}

The default condition type for \cdf{signal} and \cdf{warn} is \cdf{simple-condition}.
The default condition type for \cdf{error} and \cdf{cerror} is
\cdf{simple-error}.

\begin{defun}[Type]
simple-condition

Conditions signaled by \cdf{signal} when given a format string as a first
argument are of this type. This is a subtype of \cdf{condition}.  The
initialization keywords \cd{:format-string} and \cd{:format-arguments} are
supported to initialize the slots, which can be accessed using
\cdf{simple-condition-format-control} and
\cdf{simple-condition-format-arguments}.  If \cd{:format-arguments} is not
supplied to \cdf{make-condition}, the \emph{format-arguments} slot defaults to
\cdf{nil}.
\end{defun}

\begin{defun}[Type]
simple-warning

Conditions signaled by \cdf{warn} when given a format string as a first argument
are of this type. This is a subtype of \cdf{warning}.  The initialization
keywords \cd{:format-string} and \cd{:format-arguments} are supported to
initialize the slots, which can be accessed using
\cdf{simple-condition-format-control} and
\cdf{simple-condition-format-arguments}.  If \cd{:format-arguments} is not
supplied to \cdf{make-condition}, the \emph{format-arguments} slot defaults to
\cdf{nil}.

In implementations supporting multiple inheritance, this type will also be a
subtype of \cdf{simple-condition}.
\end{defun}

\begin{defun}[Type]
simple-error

Conditions signaled by \cdf{error} and \cdf{cerror} when given a format string
as a first argument are of this type. This is a subtype of \cdf{error}.  The
initialization keywords \cd{:format-string} and \cd{:format-arguments} are
supported to initialize the slots, which can be accessed using
\cdf{simple-condition-format-control} and
\cdf{simple-condition-format-arguments}.  If \cd{:format-arguments} is not
supplied to \cdf{make-condition}, the format-arguments slot defaults to
\cdf{nil}.

In implementations supporting multiple inheritance, this type will also be a
subtype of \cdf{simple-condition}.
\end{defun}

\begin{defun}[Function]
simple-condition-format-control condition

Accesses the format-string slot of a given \emph{condition}, which must be of
type \cdf{simple-condition}, \cdf{simple-warning}, \cdf{simple-error}, or
\cdf{simple-type-error}.
\end{defun}

\begin{defun}[Function]
simple-condition-format-arguments condition

Accesses the format-arguments slot of a given \emph{condition}, which must be of
type \cdf{simple-condition}, \cdf{simple-warning}, \cdf{simple-error}, or
\cdf{simple-type-error}.
\end{defun}

\begin{defun}[Type]
storage-condition

Conditions that relate to storage overflow should inherit from this type.  This
is a subtype of \cdf{serious-condition}.
\end{defun}

\begin{defun}[Type]
type-error

Errors in the transfer of data in a program should inherit from this type. This
is a subtype of \cdf{error}. For example, conditions to be signaled by
\cdf{check-type} should inherit from this type. The initialization keywords
\cd{:datum} and \cd{:expected-type} are supported to  initialize the slots,
which can be accessed using \cdf{type-error-datum} and
\cdf{type-error-expected-type}.
\end{defun}

\begin{defun}[Function]
type-error-datum condition

Accesses the datum slot of a given \emph{condition}, which must be of type
\cdf{type-error}.
\end{defun}

\begin{defun}[Function]
type-error-expected-type condition

Accesses the expected-type slot of a given \emph{condition}, which must be of
type \cdf{type-error}. Users of \cdf{type-error} conditions are expected to fill
this slot with an object that is a valid Common Lisp type specifier.
\end{defun}

\begin{defun}[Type]
simple-type-error

Conditions signaled by facilities similar to \cdf{check-type} may want to use
this type. The initialization keywords \cd{:format-string} and
\cd{:format-arguments} are supported to initialize the slots, which can be
accessed using  \cd{simple-condition-format-control} and
\cd{simple-condition-format-arguments}.  If \cd{:format-arguments} is not
supplied to \cdf{make-condition}, the  format-arguments slot defaults to
\cdf{nil}.

In implementations supporting multiple inheritance, this type will also be a
subtype of \cdf{simple-condition}.
\end{defun}

\begin{defun}[Type]
program-error

Errors relating to incorrect program syntax that are statically detectable
should inherit from this type (regardless of whether they are in fact statically
detected). This is a subtype of \cdf{error}. This is \emph{not} a subtype of
\cdf{control-error}.
\end{defun}

\begin{defun}[Type]
control-error

Errors in the dynamic transfer of control in a program should inherit from this
type. This is a subtype of \cdf{error}. This is \emph{not} a subtype of
\cdf{program-error}.

The errors that result from giving \cdf{throw} a tag that is not active or from
giving \cdf{go} or \cdf{return-from} a tag that is no longer dynamically
available are control errors.

On the other hand, the errors that result from naming a \cdf{go} tag or
\cdf{return-from} tag that is not lexically apparent are not control
errors. They are program errors. See \cdf{program-error}.
\end{defun}


\begin{defun}[Type]
package-error

Errors that occur during operations on packages should inherit from this
type. This is a subtype of \cdf{error}. The initialization keyword \cd{:package}
is supported to initialize the slot, which can be accessed using
\cdf{package-error-package}.
\end{defun}

\begin{defun}[Function]
package-error-package condition

Accesses the package (or package name) that was being modified or manipulated in
a \emph{condition} of type \cdf{package-error}.
\end{defun}

\begin{defun}[Type]
stream-error

Errors that occur during input from, output to, or closing a stream should
inherit from this type. This is a subtype of \cdf{error}. The initialization
keyword \cd{:stream} is supported to initialize the slot, which can be accessed
using \cdf{stream-error-stream}.
\end{defun}

\begin{defun}[Function]
stream-error-stream condition

Accesses the offending stream of a \emph{condition} of type \cdf{stream-error}.
\end{defun}

\begin{defun}[Type]
end-of-file

The error that results when a read operation is done on a stream that has no
more tokens or characters should inherit from this type. This is a subtype of
\cdf{stream-error}.
\end{defun}

\begin{defun}[Type]
file-error

Errors that occur during an attempt to open a file, or during some low-level
transaction with a file system, should inherit from this type. This is a subtype
of \cdf{error}. The initialization keyword \cd{:pathname} is supported to
initialize the slot, which can be accessed using \cdf{file-error-pathname}.
\end{defun}

\begin{defun}[Function]
file-error-pathname condition

Accesses the offending pathname of a \emph{condition} of type \cdf{file-error}.
\end{defun}

\begin{defun}[Type]
cell-error

Errors that occur while accessing a location should inherit from this type. This
is a subtype of \cdf{error}.  The initialization keyword \cd{:name} is supported
to initialize the slot, which can be accessed using \cdf{cell-error-name}.
\end{defun}

\begin{defun}[Function]
cell-error-name condition

Accesses the offending cell name of a \emph{condition} of type \cdf{cell-error}.
\end{defun}

\begin{defun}[Type]
unbound-variable

The error that results from trying to access the value of an unbound variable
should inherit from this type. This is a subtype of \cdf{cell-error}.
\end{defun}

\begin{defun}[Type]
undefined-function

The error that results from trying to access the value of an undefined function
should inherit from this type. This is a subtype of \cdf{cell-error}.
\end{defun}

\begin{defun}[Type]
arithmetic-error

Errors that occur while doing arithmetic type operations should inherit from
this type. This is a subtype of \cdf{error}. The initialization keywords
\cd{:operation} and \cd{:operands} are supported to initialize the slots, which
can be accessed using \cdf{arithmetic-error-operation} and
\cdf{arithmetic-error-operands}.
\end{defun}

\begin{defun}[Function]
arithmetic-error-operation condition

Accesses the offending operation of a condition of type \cdf{arithmetic-error}.
\end{defun}

\begin{defun}[Function]
arithmetic-error-operands condition

Accesses a list of the offending operands in a condition of type
\cdf{arithmetic-error}.
\end{defun}

\begin{defun}[Type]
division-by-zero

Errors that occur because of division by zero should inherit from this type.
This is a subtype of \cdf{arithmetic-error}.  
\end{defun}

\begin{defun}[Type]
floating-point-overflow

Errors that occur because of floating-point overflow should inherit from this
type. This is a subtype of \cdf{arithmetic-error}.
\end{defun}

\begin{defun}[Type]
floating-point-underflow

Errors that occur because of floating-point underflow should inherit from this
type. This is a subtype of \cdf{arithmetic-error}.
\end{defun}

\else % RUSSIAN

\chapter{Условия}
\label{CONDITION}

Автор: Kent M. Pitman


\section{Введение}

Обычно мы описываем функции, как если они работают в <<обычной
ситуации>>. Например, мы может сказать, что функция \cdf{+} возвращает сумму
аргументов, или что \cdf{read-char} возвращает доступный символ из входного
потока.

Однако, иногда возникают <<исключительные ситуации>>, которые в такие описания
не вписываются. Например, \cdf{+} может получить аргумент, который не является
числом, или \cdf{read-char} может получить аргумент --- поток, в котором не
осталось данных. Это разграничение между обычной и исключительной ситуациями в
некотором смысле непостоянно, но на практике оно очень полезно.

Например, предположим, функция \cdf{f} была определена только для целочисленных
аргументов, но также гарантированно определяет некорректные аргументы и
сигнализирует в этом случае ошибку. Фактически, такое описания противоречиво,
так как поведение функции для нечисловых аргументов хорошо и ясно
определено. Однако мы бы не хотели избегая парадокса строить описание как,
например, функция \cdf{f} принимает все виды аргументов (даже если при этом она
сигнализирует ошибку). Используя разграничение нормальная/исключительная
ситуации, мы можем чётко сказать, что \cdf{f} в нормальной ситуации принимает
целочисленные аргументы и сигнализирует ошибку в исключительной. Более того, мы
можем сказать, что когда мы неформально ссылаемся на определение функции, мы
имеем ввиду её поведение в нормальной ситуации. Например, мы можем неформально
сказать о \cdf{f}, как о функции, которая принимает только целочисленные
аргументы, и не почувствуем каких-либо угрызений совести. FIXME

Не все исключительные ситуации являются ошибками. Например, программа, которая
выводит длинную строку текста может придти к концу-строки (end-of-line).  Вполне
возможно, что никакого реального вреда от конца строки нет и сигнал об ошибке не
несёт критического смысла, поскольку операционная система просто переведёт
курсор на следующую строку и вывод строки может продолжаться. Однако, это может
быть интересно спроектировать протокол, где программы вывода может информировать
вызвавшего её о исключениях типа конец-строки. Вызывающей код в этом случае
должен будет в этой ситуации в это же время принять решение о дальнейших
действия. Например, вызывающий код может выбрать действие о завершении вывода,
продолжении без символа конца-строки. Однако, важная вещь в том, что отказ
вызывающего кода в предоставлении совета насчёт исключительной ситуации не
мешает выводящей программе работать правильно.

Механизмы для обработки исключительных ситуаций отличаются друг от друга. При
возникновении исключительной ситуации, программа может попытаться справиться с
ней с помощью возврата исключительного значения, возвращения дополнительного
значения, установки переменной-флага, вызова функции, выполнения специальной
передачи управления, или остановки программы или в целом, или с переходом в
отладчик.

По большей части, средства, описанные в этой главе не вводят каких-либо
принципиально новых способов борьбы с исключительными ситуациями. Они, скорее,
включают и формализуют полезные модели данный и управления потоком выполнения,
которые могут использоваться для обработки исключительных ситуаций.

Необходимый концептуальный подхода обработки ошибок, возможно, следует начать с
первого принципа, с обсуждения \emph{условий} в целом, и в конечном итоге
придти к понятию \emph{ошибки}, как одному из видов условий.
Однако, учитывая простейшее устройство технологии обработки ошибок,
объяснение механизма в целом столь же неуместно, как, например, требование к
нищему сначала научится готовить изысканное блюдо, прежде чем поесть. Таким
образом, мы сначала рассмотрим необходимое --- обработку ошибок, а затем ---
вернёмся и заполним недостающие подробности описанием всей системы.

\section{Изменения в терминологии}

В этом разделе, мы расскажем об изменениях в терминологии, которая была
определена в разделе~\ref{INTRO-ERRORS}.

\emph{Условие} --- это очень интересная ситуация в программе, которая была
обнаружена и объявлена. Позже мы также допустим, чтобы этот термин также
ссылался на объекты, которые программа использует в таких ситуациях.

\emph{Ошибка} --- это условие, при котором нормальное выполнение программы без
некоторых форм вмешательства (или пользовательского или программного, это будет
описано ниже) продолжаться не может.

Процесс, с помощью которого условие формально объявляется программой, называется
\emph{сигнализирование}. Функция \cdf{signal} является примитивным механизмом, с
помощью которого это объявление и производится. Другие абстракции, такие как
\cdf{error} и \cdf{cerror}, разработаны на основе \cdf{signal}.

В данном разделе используется следующая терминология

\begin{itemize}
\item Если сигнализирование условия или ошибки во всех случаях является частью
  контракта функции, мы говорим, что она <<сигнализирует>> или <<должна
  сигнализировать>> эту ошибку или условие.

\item Если сигнализирование условия или ошибка по некоторым важным причинам
  (например, производительность)
  является необязательным, мы говорим, что программа <<может сигнализировать>>
  это условие или ошибку. В этом случае, мы указываем, что во всех реализациях
  операция запрещена, и допускаем что некоторые реализации могут не проводить
  проверку этой ошибки.

\item Если некоторое действие не определено, и оставлено на откуп
  платформоспецифичным расширениям, мы говорит <<не определено>>,
  <<непредсказуемо>> или <<имеет неопределённый результат>>.
  Это означает, что обеспечить переносимость программы, полагаясь на результат
  этого действия, невозможно. Программа, которая попадает в неопределённую
  ситуацию может вызвать отладчик, передать управление, или непредсказуемо
  модифицировать данные.

\item В некоторых случая, где не определено лишь возвращаемое значение операции,
  но хорошо определены любые побочные действия или передача управления, мы
  говорим <<неопределённое значение>>. В этом случае количество и природа
  возвращаемых значений не определены, но можно с уверенностью ожидать возврата
  из функции.  Стоит отметить, что под это описание попадают, некоторые (хотя и
  не много) законные способы, в которых могут быть использованы такие
  возвращаемое(ые) значение(я). Например, если функция \cdf{foo} не имеет
  побочных эффектов и неопределённого значения, выражение \cd{(length (list
    (foo)))} полностью определено даже для переносимого кода.  Тем не менее,
  результат \cd{(print (list (foo)))} не определён.
\end{itemize}

\section{Обзор концепций}

В этом разделе по темам обсуждаются различные аспекты системы условий,
иллюстрируя их многочисленными примерами. В следующем разделе содержатся
определения конкретных функций, макросов и других объектов.

\subsection{Сигнализирование ошибок}

Концептуально, сигнализирование ошибок в программе это указание того, что
программа, не знает как продолжить выполнение и требует внешнего
вмешательства. Как только сигнализирована ошибка, любые советы о
продолжении должны прийти <<извне>>.

Самый простой путь сигнализирования ошибки использовать функцию \cdf{error} с
аргументами как для функции \cdf{format}, описывающие ошибку для
пользовательского интерфейса. Если была вызвана \cdf{error} и активных
обработчиков (описанных в разделах~\ref{TRAPPING-ERRORS}
и~\ref{HANDLING-CONDITIONS}) не оказалось, то в управление вмешивается отладчик
и данное сообщение выводится пользователю. Например:
\begin{lisp}
Lisp> (defun factorial (x) \\*
~~~~~~~~(cond ((or (not (typep x 'integer)) (minusp x)) \\*
~~~~~~~~~~~~~~~(error "{\Xtilde}S is not a valid argument to FACTORIAL." \\*
~~~~~~~~~~~~~~~~~~~~~~x)) \\
~~~~~~~~~~~~~~((zerop x) 1) \\
~~~~~~~~~~~~~~(t (* x (factorial (- x 1)))))) \\*
~\EV\ FACTORIAL \\
Lisp> (factorial 20) \\*
~\EV\ 2432902008176640000 \\
Lisp> (factorial -1) \\*
Error: -1 is not a valid argument to FACTORIAL. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Return to Lisp Toplevel. \\*
Debug> 
\end{lisp}
В общем, вызов \cdf{error} не может вернуть управление в то же место. Если не
была проделана специальная работа по обработке для изменения этого поведения, то
в работу вмешается отладчик и в нем не будет возможности просто продолжить работу.

Единственное исключение может быть в том, что некоторые реализации могут
содержать отладочные команды для интерактивного возврата из конкретных мест по
стеку вызовов. Однако, даже тогда такие команды не должны использоваться за
исключением того, что кто-то читает ошибочный код и понимание последствия
продолжения кода с этого места. В частности, программист может чувствовать себя
спокойно при написании примерно такого кода:
\begin{lisp}
(defun wargames:no-win-scenario () \\*
~~(when (true) (error "Pushing the button would be stupid.")) \\*
~~(push-the-button))
\end{lisp}
В этом сценарии, нет никаких шансов на то, что функция \cdf{error} вернёт
управление, и кнопка будет нажата.

\beforenoterule
\begin{sideremark}
It should be noted that the notion of
``no chance'' that the button will be pushed is relative only to the language
model; it assumes that the language is accurately implemented.  In practice,
compilers have bugs, computers have glitches, and users have been known
to interrupt at inopportune moments and use the debugger to return from
arbitrary stack frames.  Such violations of the language model are
beyond the scope of the condition system but not necessarily beyond the
scope of potential failures that the programmer should consider and defend against.
The possibility of such unusual failures may of course also influence the design of
code meant to handle less drastic situations,
such as maintaining a database uncorrupted.---KMP and GLS
\end{sideremark}
\afternoterule

В некоторых случаях, программист может один, хорошо продуманный план о том, что
делать в случае ошибки. В этом случае, он может использовать функцию
\cdf{cerror}, которая указывает информацию о том, что произойдёт, если
пользователь просто нажмёт <<продолжить>> и выполнение продолжиться сразу за
вызовом этой функции. Например:
\begin{lisp}
Lisp> (defun factorial (x) \\*
~~~~~~~~(cond ((not (typep x 'integer)) \\*
~~~~~~~~~~~~~~~(error "{\Xtilde}S is not a valid argument to FACTORIAL." \\*
~~~~~~~~~~~~~~~~~~~~~~x)) \\
~~~~~~~~~~~~~~((minusp x) \\*
~~~~~~~~~~~~~~~(let ((x-magnitude (- x))) \\*
~~~~~~~~~~~~~~~~~(cerror "Compute -({\Xtilde}D!) instead." \\*
~~~~~~~~~~~~~~~~~~~~~~~~~"(-{\Xtilde}D)! is not defined." x-magnitude) \\*
~~~~~~~~~~~~~~~~~(- (factorial x-magnitude)))) \\
~~~~~~~~~~~~~~((zerop x) 1) \\
~~~~~~~~~~~~~~(t (* x (factorial (- x 1)))))) \\*
~\EV\ FACTORIAL \\
Lisp> (factorial -3) \\*
Error: (-3)! is not defined. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Compute -(3!) instead. \\*
~2: Return to Lisp Toplevel. \\*
Debug> :continue 1 \\
~\EV\ -6
\end{lisp}

\subsection{Перехват ошибок}
\label{TRAPPING-ERRORS}

По умолчанию, вызов \cdf{error} приведёт к вмешательству отладчика. Но вы можете
различными способами воспрепятствовать этому поведению. Самый простой (и
самый грубый) инструмент для исключения вмешательства отладчика ---
использование \cdf{ignore-errors}. В обычной ситуации, формы в теле
\cdf{ignore-errors} вычисляются последовательно и возвращает значение последней
из них. Если сигнализируется ошибка \cdf{error}, \cdf{ignore-errors} немедленно
возвращает два значение, \cdf{nil} и условие, которое было
сигнализировано. Отладчик не вызывается и никакого сообщения об ошибке не
выводится. Например:
\begin{lisp}
Lisp> (setq filename "nosuchfile") \\
~\EV\ "nosuchfile" \\
Lisp> (ignore-errors (open filename :direction :input)) \\
~\EV\ NIL \textrm{and} \#<FILE-ERROR 3437523>
\end{lisp}
Второе возвращённое значение является объектом, отображающим тип ошибки. Он
подробнее описан в разделе~\ref{OBJECT-0RIENTED-BASIS}.

Однако, в большинстве случае \cdf{ignore-errors} не желательна, так как она
обрабатывает слишком много типов ошибок. В отличие от утверждений некоторых
людей, программа, которая не вызывает отладчик не обязательно лучше той, которая
вызывает.
Чрезмерное использование \cdf{ignore-errors} может удерживать программу от
вмешательства отладчика, но надёжность программы от этого не увеличится, потому
что программа может продолжить выполнение после ошибок, которые вами не
учитывались. В целом, лучше попытаться обработать ряд ошибок, которые, как вы
уверены, обязательно могут случиться. Таким образом, при появлении не ожидаемых
ошибок, вы сможете о них узнать.

\cdf{ignore-errors} является полезным частным случаем от более общей
функциональности, \cdf{handler-case}, которая позволяет программистам
обрабатывать отдельные виды условий (включая не ошибочные условия) без указания
того, что произойдёт при сигнализировании других видов условий. Например,
эквивалентный код, как если бы использовалась \cdf{ignore-errors}, представлен в
следующем примере:
\begin{lisp}
Lisp> (setq filename "nosuchfile") \\
~\EV\ "nosuchfile" \\
Lisp> (handler-case (open filename :direction :input) \\
~~~~~~~~(error (condition) \\
~~~~~~~~~~(values nil condition))) \\
~\EV\ NIL \textrm{and} \#<FILE-ERROR 3437525>
\end{lisp}
Однако, при использовании \cdf{handler-case} можно указать более специфичный тип
условия, чем просто <<error>>. Типы условий освещены будут освещены более
подробно позже, но синтаксис примерно выглядит так:
\begin{lisp}
Lisp> (makunbound 'filename) \\
~\EV\ FILENAME \\
Lisp> (handler-case (open filename :direction :input) \\
~~~~~~~~(file-error (condition) \\
~~~~~~~~~~(values nil condition))) \\
Error: The variable FILENAME is unbound. \\
To continue, type :CONTINUE followed by an option number: \\
~1: Retry getting the value of FILENAME. \\
~2: Specify a value of FILENAME to use this time. \\
~3: Specify a value of FILENAME to store and use. \\
~4: Return to Lisp Toplevel. \\
Debug> 
\end{lisp}

\subsection{Обработка условий}
\label{HANDLING-CONDITIONS}

Слепая передача управления в \cdf{handler-case} является единственно возможным
способом восстановить работу после сигнализирования условия. Низкоуровневый
механизм предоставляет большую гибкость в том, как продолжить выполнение
программы после сигнализирования условия.

Основная идея в обработке условия в том, что часть кода, называемого
\emph{сигнальщик}, распознаёт и объявление возникновение исключительной ситуации
с помощью \cdf{signal} или другой функции на основе \cdf{signal} (такой как
\cdf{error}).

Процесс сигнализирования включает поиск для и запуск \emph{обработчика} - части
кода, который будет пытаться соответственно справиться с ситуацией.

Если обработчик найден, он может или \emph{обработать} ситуацию с помощью
некоторой нелокальной передачи управления, или \emph{отклонить} обработку
ситуации с помощью отказа от выполнения нелокальной передачи управления. Если он
отклонил обработку, будет выполнен поиск других обработчиков.

Так как лексическое окружение сигнальщика может быть не доступным для
обработчика, для отображения состояния ситуации создаётся структура, называемая
\emph{условие}. Условие может быть создано как явным вызовом
\cdf{make-condition} и передачей в функцию, например, \cdf{signal}, так и неявно
в функции \cdf{signal} при использовании других аргументов.

При обработке ошибки, обработчик может использовать любой нелокальный выход
(нелокальную передачу управления), такой как \cdf{go} на тег в \cdf{tagbody},
\cdf{return} из \cdf{block}, или \cdf{throw} в \cdf{catch}. Кроме того, для
удобства в обработке исключений над этими примитивами созданы структурированные
абстракции.

Обработчик может быть динамически доступным для программы если создать его с
помощью \cdf{handler-bind}. Например, для создания обработчика для условия типа
\cdf{arithmetic-error}, можно записать:
\begingroup
\makeatletter
\def\@listi{\leftmargin\leftmargini \labelsep\leftmargin
   \parsep 3pt\relax
   \topsep 4pt plus 9pt\relax
   \itemsep\topsep}
\makeatother
\begin{lisp}
(handler-bind ((arithmetic-error \emph{handler}))\emph{body})
\end{lisp}
Обработчик является функцией одного аргумента, а, именно, условия. Если во время
выполнения форм \emph{body} сигнализируется условие указанного типа (и внутри не
было установленных обработчиков условия), будет вызван данный обработчик с данным
условием, позволяя последнему передать управление куда-либо. Например, можно
записать макрос, который выполняет тело, возвращая его значение(я) или два
значения: \cdf{nil} и объект условия.
\begin{lisp}
(defmacro without-arithmetic-errors (\&body forms) \\
~~(let ((tag (gensym))) \\
~~~~`(block ,tag \\
~~~~~~ (handler-bind ((arithmetic-error \\
~~~~~~~~~~~~~~~~~~~~~~~~~\#'(lambda (c)~~~~~;\textrm{Argument \cdf{c} is a condition} \\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (return-from ,tag (values nil c))))) \\
~~~~~~~~~,@body)))) \\
\end{lisp}
\endgroup
Обработчик выполняется в динамическом контексте сигнальщика, за исключением
того, что множество доступных обработчиков условий будут пересвязаны со
значениями, которые были активны во время того как активизировался данный
обработчик. Если обработчик отклонил (отказался) от обработки (то есть, не
передал управление), то выбираются другие обработчики. Если обработчик не был
найден и условия было сигнализировано с помощью \cdf{error} или \cdf{cerror}
(или некоторой функции, такой как \cdf{assert}, которая ведёт себя также как
названные), в работу вмешивается отладчик и работает в этом же динамическом
контексте сигнальщика.

\subsection{Объектно-ориентированные концепции обработки условий}
\label{OBJECT-0RIENTED-BASIS}

Естественно, возможность обработчика качественно обработать исключительную
ситуацию зависит от того, какой полноты информацию она предоставляет. Например,
если все ошибки сигнализируется так:
\begin{lisp}
(error "\emph{some format string}")
\end{lisp}
тогда всё что получит обработчик - объект типа \cdf{simple-error}, в котором
есть слот со строкой.

Если пользоваться только таким способом, то для различия ошибок придётся
пользоваться функцией \cdf{string-equal}, и при каждом изменении строки об
ошибке менять все сравнения в обработчиках, что не очень-то способствует
самочувствию программиста. Этот феномен был самым большим фейлом в предыдущей
системе обработки ошибок в Lisp'е.  Принципиально важно отделить строки
сообщений об ошибках (человеческий интерфейс) от объектов, которые формально
представляют состояние ошибки (программный интерфейс). Таким образом мы имеем
понятие типизированных условий и формальные операции над этими условиями,
которые позволяют структурировано инспектировать эти условия.

Этот объектно-ориентированный подход в обработке условий имеет следующие
важные преимущества по сравнению с текстовым подходом:
\begin{itemize}
\item Условия классифицируются в соответствии с отношениями подтипов, что делает
  лёгким проверку категории условия.

\item У условий есть слоты со значениями, через которые передаются параметры от
  программы, сигнализирующей ошибку в программу, которая её обрабатывает.

\item Наследование методов и слотов уменьшает количество явных спецификаций,
  необходимых для достижения интересных эффектов.
\end{itemize}

Некоторые типы условий определяются в этом документе, но их множество может
расширяться с помощью \cdf{define-condition}.
Common Lisp'овые типы условий фактически являются CLOS классами, и объекты
условий являются простыми CLOS объектами. \cdf{define-condition} просто
предоставляет интерфейс абстракции, который для определения условий чуть более
удобен, чем \cdf{defclass}.

Вот простой пример, мы определяем функцию двух аргументов \cdf{divide}, которая
похожа на функцию \cdf{/}, но сигнализирует чуть стилизованные сообщения об
ошибках:
\begin{lisp}
(defun divide (numerator denominator) \\
~~(cond ((or (not (numberp numerator)) \\
~~~~~~~~~~~~~(not (numberp denominator))) \\
~~~~~~~~~(error "(DIVIDE '{\Xtilde}S '{\Xtilde}S) - Bad arguments." \\
~~~~~~~~~~~~~~~~numerator denominator)) \\
~~~~~~~~((zerop denominator) \\
~~~~~~~~~(error 'division-by-zero \\
~~~~~~~~~~~~~~~~:operator 'divide \\
~~~~~~~~~~~~~~~~:operands (list numerator denominator))) \\
~~~~~~~~(t ...)))
\end{lisp}
Следует отметить, что в первом выражении мы использовали \cdf{error} со
строковым аргументом и во втором выражении мы указали конкретный тип условия,
\cdf{division-by-zero}. В случае строкового аргумент, тип сигнализируемого
условия будет \cdf{simple-error}.

Конкретный вид сигнализируемой ошибки может быть важен в зависимости от того где
находятся активные обработчики. Например, \cdf{simple-error} наследуется от типа
\cdf{error}, которая в свою очередь наследуется от типа \cdf{condition}. С
другой стороны, \cdf{division-by-zero} наследуется от \cdf{arithmetic-error},
которая наследуется от \cdf{error}, которая наследуется от \cdf{condition}. Так
что, если существует обработчик для \cdf{arithmetic-error} в момент когда
сигнализируется \cdf{division-by-zero}, тогда этот обработчик будет
вызван. Однако если в том же контексте будет вызвана \cdf{simple-error}, тип
обработчика \cdf{arithmetic-error} вызываться не будет.

\subsection{Перезапуски (рестарты)}
\label{RESTARTS}
Common Lisp'овая система условий создаёт чёткое разграничение между
сигнализированием ошибки определённого типа и сообщением о том, как
соответственно восстанавливать выполнение программы. В приведённом выше примере
с \cdf{divide} просто сигнализирование ошибки не означает готовность
сигнализатора к сотрудничеству в каких-либо корректирующих действиях. Например, 
следующий пример взаимодействия показывает, что для восстановление предлагается
только <<Вернуться на верхний уровень>>.
\begin{lisp}
Lisp> (+ (divide 3 0) 7) \\
Error: Attempt to divide 3 by 0. \\
To continue, type :CONTINUE followed by an option number: \\
~1: Return to Lisp Toplevel. \\
Debug> :continue 1 \\
Returned to Lisp Toplevel. \\
Lisp>
\end{lisp}
При обнаружении ошибки и была вызвана функция \cdf{error}, выполнение не может
нормально продолжаться, потому что \cdf{error} не будет непосредственно
возвращать управление. Управление может быть передано в другие точки программы,
однако, с помощью специально установленного <<перезапуска>>.

\subsection{Анонимные перезапуски (рестарты)}

Самый простой вид перезапуска включает в себя структурированную передачу
управления с помощью макроса с именем \cdf{restart-case}. Форма
\cdf{restart-case} позволяет выполнять кусок кода в контексте, где активны ноль
или более перезапусков, и где, если один из этих перезапусков будет <<вызван>>,
управление будет передано на соответствующий пункт в \cdf{restart-case}
формы. Например, мы могли бы переписать предыдущую функцию \cdf{divide}
например, следующим образом.
\begin{lisp}
(defun divide (numerator denominator) \\
~~(loop \\
~~~~(restart-case \\
~~~~~~~~(return \\
~~~~~~~~~~(cond ((or (not (numberp numerator)) \\
~~~~~~~~~~~~~~~~~~~~~(not (numberp denominator))) \\
~~~~~~~~~~~~~~~~~(error "(DIVIDE '{\Xtilde}S '{\Xtilde}S) - Bad arguments." \\
~~~~~~~~~~~~~~~~~~~~~~~~~numerator denominator)) \\
~~~~~~~~~~~~~~~~((zerop denominator) \\
~~~~~~~~~~~~~~~~~(error 'division-by-zero \\
~~~~~~~~~~~~~~~~~~~~~~~~:operator 'divide \\
~~~~~~~~~~~~~~~~~~~~~~~~:operands (list numerator denominator))) \\
~~~~~~~~~~~~~~~~(t ...))) \\
~~~~~~(nil (arg1 arg2) \\
~~~~~~~~~~:report "Provide new arguments for use by DIVIDE." \\
~~~~~~~~~~:interactive \\
~~~~~~~~~~~~(lambda () \\
~~~~~~~~~~~~~~~(list (prompt-for 'number "Numerator: ") \\
~~~~~~~~~~~~~~~~~~~~~(prompt-for 'number "Denominator: "))) \\
~~~~~~~~(setq numerator arg1 denominator arg2)) \\
~~~~~~(nil (result) \\
~~~~~~~~~~:report "Provide a value to return from DIVIDE." \\
~~~~~~~~~~:interactive \\
~~~~~~~~~~~~(lambda () (list (prompt-for 'number "Result: "))) \\
~~~~~~~~(return result)))))
\end{lisp}

\beforenoterule
\begin{sideremark}
    The function \cdf{prompt-for} used in this chapter in a number of places is
    not a part of Common Lisp.  It is used in the examples in this chapter only to keep
    the presentation simple.  It is assumed to accept a type specifier
     and optionally a format string and associated arguments.  It uses the
    format string and associated arguments as part of an interactive prompt,
    and uses \cdf{read} to read a Lisp object; however, only an object of the
    type indicated by the type specifier is accepted.

    The question of whether or not \cdf{prompt-for} (or something like it) would be a
    useful addition to Common Lisp is under consideration by X3J13, but as of
    January 1989 no action has been taken. In spite of its use in a number of examples,
    nothing in the Common Lisp Condition System depends on this function.
\end{sideremark}
\afternoterule

В примере, \cdf{nil}, указанный в начале каждого выражения, означает, что это
<<анонимный>> перезапуск. Анонимные перезапуски обычно вызываются только из
отладчика. Мы покажем позже, что возможно иметь <<именованный перезапуск>>,
который может быть вызван из кода, без необходимости пользовательского
вмешательства.

Если аргументы для анонимного перезапуска являются обязательными, тогда должна
быть предоставлена специальная информация о том, что отладчик должен
использовать в качестве аргументов. Здесь для указания этой информации
используется ключевой символ \cd{:interactive}.

Ключевое слово \cd{:report} представляет информацию, для использования когда
предоставляет параметр перезапуска пользователю (в отладчике, например).

Вот простое взаимодействие, которое использует перезапуски предоставленные
изменённой версией \cdf{divide}:
\begin{lisp}
Lisp> (+ (divide 3 0) 7) \\
Error: Attempt to divide 3 by 0. \\
To continue, type :CONTINUE followed by an option number: \\
~1: Provide new arguments for use by the DIVIDE function. \\
~2: Provide a value to return from the DIVIDE function. \\
~3: Return to Lisp Toplevel. \\
Debug> :continue 1 \\
1 \\
Numerator: 4 \\
Denominator: 2 \\
~\EV\ 9
\end{lisp}

\subsection{Именованные перезапуски (рестарты)}

В дополнение к анонимным перезапускам, можно задавать перезапуски с именами,
которые могут быть вызваны из кода, используя это имя. В качестве простейшего
примера, для сложения \cd{3} и \cd{1} и возвращения \cd{4}, можно записать:
\begin{lisp}
(restart-case (invoke-restart 'foo 3) \\
~~(foo (x) (+ x 1)))
\end{lisp}
Этот пример концептуально аналогичен следующему:
\begin{lisp}
(+ (catch 'something (throw 'something 3)) 1)
\end{lisp}

Для более реалистичного примера, код функции \cdf{symbol-value} может
сигнализировать ошибку несвязанной переменной так:
\begin{lisp}
(restart-case (error "The variable {\Xtilde}S is unbound." variable) \\*
~~(continue () \\*
~~~~~~:report \\*
~~~~~~~~(lambda (s)~~~~~;\textrm{Аргумент \cdf{s} --- поток} \\*
~~~~~~~~~~(format s "Retry getting the value of {\Xtilde}S." variable)) \\*
~~~~(symbol-value variable)) \\
~~(use-value (value) \\*
~~~~~~:report \\*
~~~~~~~~(lambda (s)~~~~~;\textrm{Аргумент \cdf{s} --- поток} \\*
~~~~~~~~~~(format s "Specify a value of {\Xtilde}S to use this time." \\*
~~~~~~~~~~~~~~~~~~variable)) \\*
~~~~value) \\
~~(store-value (value) \\*
~~~~~~:report \\*
~~~~~~~~(lambda (s)~~~~~;\textrm{Аргумент \cdf{s} --- поток} \\*
~~~~~~~~~~(format s "Specify a value of {\Xtilde}S to store and use." \\*
~~~~~~~~~~~~~~~~~~variable)) \\*
~~~~(setf (symbol-value variable) value) \\*
~~~~value))
\end{lisp}
Если это будет частью реализации \cdf{symbol-value}, тогда пользователи смогут
писать разные автоматические обработчики ошибок о несвязанных
переменных. Например, для вычисления несвязанной переменной самой в себя, можно
записать:
\begin{lisp}
(handler-bind ((unbound-variable \\
~~~~~~~~~~~~~~~~~\#'(lambda (c)~~~~~;\textrm{Аргумент \cdf{c} --- условие} \\
~~~~~~~~~~~~~~~~~~~~~(when (find-restart 'use-value) \\
~~~~~~~~~~~~~~~~~~~~~~~(invoke-restart 'use-value \\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(cell-error-name c)))))) \\
~~\emph{body})
\end{lisp}

\subsection{Функции перезапусков (рестартов)}

Для частого использования перезапусков, удобно определить программный интерфейс,
который будет скрывать использование \cdf{invoke-restart}. Такой программный
интерфейс для перезапусков называется \emph{restart functions}.

Обычно функция имеет такое же имя, что и перезапуск. Предопределённые функции
\cdf{abort}, \cdf{continue}, \cdf{muffle-warning}, \cdf{store-value} и
\cdf{use-value} являются функциями перезапусков. Предыдущий пример может быть
записан с использованием \cdf{use-value}:
\begin{lisp}
(handler-bind ((unbound-variable \\
~~~~~~~~~~~~~~~~~~~\#'(lambda (c)~~~~~;\textrm{Argument \cdf{c} is a condition} \\
~~~~~~~~~~~~~~~~~~~~~~~(use-value (cell-error-name c))))) \\
~~\emph{body})
\end{lisp}

\subsection{Сравнение перезапусков и catch/throw}

Одна важная возможность в том, что предоставляет \cdf{restart-case} (или
\cdf{restart-bind}), и не предоставляет \cdf{catch}, это получение информации о
доступных точках для передачи управления без самой попытки передачи. Можно
например написать так:
\begin{lisp}
(ignore-errors (throw ...))
\end{lisp}
что является обеднённой реализацией 
\begin{lisp}
(when (find-restart 'something) \\*
~~(invoke-restart 'something))
\end{lisp}
однако с помощью \cdf{ignore-errors} и \cdf{throw} невозможно реализовать
следующий код:
\begin{lisp}
(when (and (find-restart 'something) \\*
~~~~~~~~~~~(find-restart 'something-else)) \\*
~~(invoke-restart 'something))
\end{lisp}
или даже такой:
\begin{lisp}
(when (and (find-restart 'something) \\
~~~~~~~~~~~(yes-or-no-p "Do something? ")) \\
~~(invoke-restart 'something))
\end{lisp}
так как уровень инспекции кода в простом коде
\begin{lisp}
(ignore-errors (throw ...))
\end{lisp}
слишком примитивный --- после получения информации о переходе, немедленно
производится и сам переход.

Многие программисты используют ранее развивающуюся стратегию, как например:
\begin{lisp}
(defvar *foo-tag-is-available* nil) \\
\\
(defun fn-1 () \\
~~(catch 'foo \\
~~~~(let ((*foo-tag-is-available* t)) \\
~~~~~~... (fn-2) ...))) \\
\\
(defun fn-2 () \\
~~... \\
~~(if *foo-tag-is-available* (throw 'foo t)) \\
~~...)
\end{lisp}
Функциональность от \cdf{restart-case} и \cdf{find-restart} предназначена
для стандартизированного протокол для такого типа информации, при коммуникации
между написанными независимо друг от друга программами. Поэтому модульность и
возможность отладки для этих программ не нарушаются.

Другое отличие между функциональностями перезапусков и \cdf{catch}/\cdf{throw}
заключается в том, что \cdf{catch} с некоторым тегом полностью скрывают любые
внешние формы \cdf{catch} с одноимённым тегом. Из-за наличия
\cdf{compute-restarts}, есть возможность для просмотра скрытых перезапусков,
которые могут быть полезны в некоторых ситуациях (в частности в интерактивном
отладчике).

\subsection{Обобщённые перезапуски}
\label{LAST-RESTARTS-SECTION}

\cdf{restart-case} является механизмом, который поддерживает только императивную
передачу управления в связанные перезапуски. \cdf{restart-case} построена на
низкоуровневом механизме с названием \cdf{restart-bind}, который не принуждает к
передаче управления.

\cdf{restart-bind} для \cdf{restart-case}, как \cdf{handler-bind} для
\cdf{handler-case}.
Синтаксис выглядит так:
\begin{lisp}
(restart-bind ((\emph{name} \emph{function} . \emph{options})) . \emph{body})
\end{lisp}
Формы \emph{body} выполняются в динамическом окружении, внутри которого будет
вызвана функция \emph{function}, где бы ни была вызвана форма
\cd{(invoke-restart '\emph{name})}.
Аргументы \emph{options} перечисляются с помощью ключевых символом и
используются для передачи информации, такой, например, какую предоставляет
ключевой символ \cd{:report} в \cdf{restart-case}.

\cdf{restart-case} раскрывается в вызов \cdf{restart-bind}, где функция просто
делает безусловную передачу выполнения в конкретный код, указывая при этом в
структурированном виде <<аргументную>> информацию.

Можно также записывать перезапуски, которые не передают управления. Такие
перезапуски могут быть полезны для реализации различных специальных команд для
отладчика, которые представляют интерес только в конкретной ситуации. Например,
можно представить ситуацию, в которой для файлов закончилось место и для
продолжения операции было освобождено место в директории \cdf{dir}:
\begin{lisp}
(restart-bind ((nil \#'(lambda () (expunge-directory dir)) \\
~~~~~~~~~~~~~~~~~~~~:report-function \\
~~~~~~~~~~~~~~~~~~~~~~\#'(lambda (stream) \\
~~~~~~~~~~~~~~~~~~~~~~~~~~(format stream "Expunge {\Xtilde}A." \\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(directory-namestring dir))))) \\
~~(cerror "Try this file operation again." \\
~~~~~~~~~~'directory-full :directory dir))
\end{lisp}
В этом случае, должен вмешаться отладчик и пользователь сначала освободит место
(это не приводит к передаче управления из отладчика куда-либо) и затем повторит операцию:
\begin{lisp}
Lisp> (open "FOO" :direction :output) \\
Error: The directory PS:<JDOE> is full. \\
To continue, type :CONTINUE followed by an option number: \\
~1: Try this file operation again. \\
~2: Expunge PS:<JDOE>. \\
~3: Return to Lisp Toplevel. \\
Debug> :continue 2 \\
Expunging PS:<JDOE> ... 3 records freed. \\
Debug> :continue 1 \\
~\EV\ \#<OUTPUT-STREAM "PS:<JDOE>FOO.LSP" 2323473>
\end{lisp}

\subsection{Интерактивная обработка условий}

Когда программа не знает как продолжить выполнение, и нет активных обработчиков,
которые могли бы дать совет по этому поводу, тогда может придти <<интерактивный
обработчик условий>> или, другими словами, <<отладчик>>. Это неявно происходит
при использовании таких функций, как \cdf{error} и \cdf{cerror}, или явно с
помощью функции \cdf{invoke-debugger}.

Интерактивный обработчик условий никогда не возвращает управления напрямую. Он
возвращает управление с помощью нелокальной структурированной передачи
управления в специально определённые точки перезапуска, которые могли быть
установлены как системой, так и пользовательским кодом. Механизмы, которые
поддерживают создание таких структурированных точек перезапуска для портируемого
кода изложены в разделах с~\ref{RESTARTS} по~\ref{LAST-RESTARTS-SECTION}.

Фактически, реализации могут также содержать расширенную функциональность для
отладки, которая позволяет возврат из произвольного фрейма стека. Не смотря на
то, такие команды часто полезны на практике, их действия зависят от
реализации, потому что они нарушают абстрагированность Common Lisp'овой
программы. Результаты использования таких команд настоящим стандартом не
определены.

\subsection{Важные условия}

Макрос \cdf{ignore-errors} будет ловить условия типа \cdf{error}. Однако
существуют также условия других типов.

Некоторые условия не считаются ошибками, но всё равно являются важными. Такие
условия называются \emph{важными условиями}, и для их представления используется
тип \cdf{serious-condition}. Условия, которые, например, могут сигнализироваться
для <<переполнения стека>> или <<исчерпанности хранилища>>, относятся к данной
категории.

Тип \cdf{error} является подтипом \cdf{serious-condition}, и технически было бы
правильным использовать термин <<важное условие>> для ссылки на все важные
условия, будь то ошибки или нет. Однако, обычно мы используется термин <<важное
условие>> для ссылки на вещи типа \cdf{serious-condition}, но не типа
\cdf{error}.

Смысл в разницу между ошибками и другими серьёзными условиями в том, что
некоторые условия возникают по причинам, которые выходят за рамки Common
Lisp'а. Например, мы знаем, что стек обычно используется для реализации вызова
функций, и мы знаем, что стеки имеют конечный размер и могут переполнятся. Так
как размер стека может меняться от реализации к реализации, от сессии к сессии,
или от вызова к вызову функции, то выражение \cd{(ignore-errors (+~a~b))},
которое будет возвращать разные значения, в определённый момент, например, из-за
переполнения стека. Поэтому, \cdf{ignore-errors} ловит условия только типа
\cdf{error}, но не все \cdf{serious-condition}. Для обработки других условий
может быть использована низкоуровневая функциональность (такая как
\cdf{handler-bind} или \cdf{handler-case}).

По соглашению, для сигнализирования условий типа \cdf{serious-condition}
(включая \cdf{error}) функция \cdf{error} предпочтительнее чем \cdf{signal}.  It
is the use of the function \cdf{error}, and not the type of the condition being
signaled, that actually causes the debugger to be entered.


\subsection{Неважные условия}

Некоторые условия не являются ни ошибками, ни важными. Они сигнализируются для
того, чтобы дать другой программе возможность вмешаться, но если никакого
действия не произошло, вычисление просто обычным образом продолжается.

Например, реализация может выбрать сигнализирование неважного (и зависимого от
реализации) условия, называемого \cdf{end-of-line}, когда вывод достигает
последнего символа в строке. В такой реализации, сигнализирование такого условия
позволяет другим программа вмешаться, выполняя вывод с переводом строки.

По соглашению, для неважных условий используется функция \cdf{signal}. Возможно
сигнализирование важного условия с использованием \cdf{signal}, и если условие
не было обработано, отладчик бы не вмешивался. Однако, по соглашению,
обработчики будут всегда склонны считать, что важные условия и ошибки
сигнализируются с помощью функции \cdf{error} (и таким образом будет вмешиваться
интерактивный обработчик условия) и, что они должны работать во избежание
этого. FIXME

\subsection{Типы условий}

Некоторые типы условий определены в самой системе. Все типы условий являются
подтипами \cdf{condition}. То есть, \cd{(typep~\emph{x} 'condition)} является
истиной тогда и только тогда, когда значение \emph{x} является условием.

Типы условий допускают множественное наследование. FIXME

\subsection{Сигнализирование условий}

При сигнализировании условия система пытается найти наиболее соответствующий
обработчик и вызвать его.

Обработчики устанавливаются динамически с помощью \cdf{handler-bind} или
абстракций над \cdf{handler-bind}.

Если был найден соответствующий обработчик, то он вызывается. В некоторых
случаях, обработчик может \emph{отклонить вызов} просто вернув управления, и без
нелокальной передачи его. В таких случаях, поиск соответствующего обработчика
продолжается в таком же стиле.

Если обработчик найден не быть, или если все обработчики, которые были найдены
отклонили предложение, \cdf{signal} возвращает \cdf{nil}.


Несмотря на то, как следует из описания выше, пожалуй стоит отметить явно, что
процедура поиска, описанная здесь, будет предпочитать общий, но более
(динамически) локальный обработчик, чем специфичный, но менее (динамически)
локальный обработчик. Опыт работы с существующими системами показывает, что это
разумный подход и работает должным образом в большинстве ситуаций.  Следует
проявлять осторожность при связывании обработчика для самых общих видов условий,
таких, как это делается в \cdf{ignore-errors}. Часто более целесообразно
связывание для более специфичного типа условия, чем для \cdf{error}.

\subsection{Пересигнализирование условий}

Следует отметить что сигнализирование условий не имеет побочных эффектов для
этого условия, и что динамического состояния для хранения объекта условия тоже
нет. Иногда бывает необходимо закешировать объект условия для повторного
использования, пересигнализирования изнутри обработчиков, или сохранить где-либо
 для использования в будущем.

Например, системе необходимо выделить память под объекты типа
\cdf{storage-condition}, так, чтобы они могли быть сигнализированы в нужное
время без попыток выделения памяти.

\subsection{Обработчики условий}
\label{CONDITION-HANDLERS}

\emph{Обработчик} является функцией одного аргумента, а именно, условия для
обработки. Обработчик может проинспектировать объект для того, чтобы быть
уверенным в <<интересности>> оного.

Обработчик вызывается в динамическом контексте сигнальщика, за исключением того,
если множество доступных обработчиков было пересвязано перед обработкой
условия. Целью является предотвращение бесконечной рекурсии из-за ошибок в
обработчике.

После инспекции условия, обработчик может выполнить одно из следующих действий:
\begin{itemize}
\item Может \emph{отклонить} обработку условия (просто вернув управление). Когда
  это происходит, возвращённые значения игнорируются, и процедура поиска
  продолжает свою работу, как будто бы ничего и не случилось. Выполняется
  следующий обработчик, а если такой не был найден, условие остаётся
  необработанным.
\item Может \emph{обработать} условие (выполнив какую-либо нелокальную передачу
  управления). Это может быть сделано примитивно с помощью \cdf{go},
  \cdf{return} или \cdf{throw}, или с помощью такой абстракции, как \cdf{abort}
  или \cdf{invoke-restart}.
\item Может сигнализировать другое условие.
\item Может вызвать интерактивный отладчик.
\end{itemize}
Фактически последние два действия (сигнализирование другого условия или вызов
отладчика) просто перекладывают решение на кого-либо другого. В конечном счёте,
все что обработчики могут сделать это обработать или отклонить.

\subsection{Вывод условий}

Когда \cdf{*print-escape*} является \cdf{nil} (например, когда используются
функция \cdf{princ} или директива \cd{{\Xtilde}A} для \cdf{format}), , будет
вызван метод для вывода условия. Это будет быть сделано автоматически в функциях,
таких как \cdf{invoke-debugger}, \cdf{break} и \cdf{warn}, но иногда бывает
полезно иметь возможность повлиять на вывод условия. Например,
\begin{lisp}
(let ((form '(open "nosuchfile"))) \\
~~(handler-case (eval form) \\
~~~~(serious-condition (c) \\
~~~~~~(format t "{\Xtilde}\&Вычисление {\Xtilde}S неуспешно:{\Xtilde}\%{\Xtilde}A" form c))))
\end{lisp}
может вывести что-то вроде
\begin{lisp}
Вычисление (OPEN "nosuchfile") неуспешно: \\
Файл "nosuchfile" не был найден.
\end{lisp}

Некоторые предложения о форме текст, введённый в докладе методы:
\begin{itemize}
\item Сообщение в целом, должно быть законченным предложением, начиная с буквы и
  заканчивая соответствующими знаками препинания (обычно точкой).

 \item Сообщение \emph{не должно включать} вводный текст, такой как
   <<\cd{Ошибка:}>> или <<\cd{Предупреждение}>> и не должны завершать символом
   новой строки. Такой текст будет добавлен автоматически в соотвествие с
   контекстом.

 \item Исключением случаев, когда это неизбежно, символы табуляции не должны
   использоваться в сообщениях об ошибках. Его действие может варьироваться от
   одной реализации к другой и может вызывать проблемы даже в рамках одной
   реализации, поскольку он может делать разные вещи в зависимости от колонки,
   в которой начинается отчёт об ошибках.

  \item Однострочные сообщения являются предпочтительными, но символ новой
    строки в середине длинного сообщения является приемлемым.

  \item Если любая программа (например, отладчик) отображает сообщения с
    отступом от преобладающее левое поле (например, с отступом семь символов,
    из-за слова <<\cd{Ошибка:}>>), то программа будет заботиться о вставке
    соответствующего отступа в дополнительные линии многострочного сообщения об
    ошибке. Кроме того, программа выводящая сообщение об ошибках с точками с
    запятой, должна заботиться о вставке точки с запятой в начале каждой строки
    многострочного сообщения об ошибке. (Вызывающий \cdf{error} не может
    предвидеть все такие возможные стили и т.д., поэтому это возложено на
    выводящего сообщение, чтобы произвести любые необходимые изменения.)
\end{itemize}

Когда \cdf{*print-escape*} не равно \cdf{nil}, объект должен быть выведен в
некотором полезном виде в соотвествие со стилем реализации. Не нужно чтобы
данный вывод был считываемым с помощью \cdf{read}. Что-нибудь вроде
\cd{\#<ARITHMETIC-ERROR~1734>} достаточно.

Указание \cd{(:report \emph{fn})} для \cdf{define-condition} при определении
типа условия \emph{C} эквивалентно
отдельному определению метода:
\begin{lisp}
(defmethod print-object ((x \emph{C}) stream) \\*
~~(if *print-escape* \\*
~~~~~~(call-next-method) \\*
~~~~~~(funcall \#'\emph{fn} x stream)))
\end{lisp}
Следует отметить, что метод использует \emph{fn} для вывода условия только
тогда, когда \cdf{*print-escape*} имеет значение \cdf{nil}.

\section{Программный интерфейс системы условий}

Данный раздел описывает функции, макросы, переменные и типы условий для Системы
Условий Common Lisp'а.

\subsection{Сигнализирование условий}
\label{SIGNALLING-CONDITIONS}

Функции из этого раздела предоставляют различные механизмы для сигнализирования
предупреждений, остановок, исправимых и неисправимых ошибок.

\begin{defun}[Функция]
error datum &rest arguments

Функция сигнализирует условие. Если условие не было обработано, вызывается
\cd{(invoke-debugger \emph{condition})}. В следствие данного вызова \cdf{error}
никогда напрямую не возвращает управление вызвавшему её. Выход из данной функции
осуществляется с помощью нелокальной передачи управления в обработчике или
командой в интерактивном отладчике.

Если \emph{datum} является условием, тогда это условие и используется.
В этом случае непустой список аргументов \emph{arguments} является ошибкой, то
есть \cdf{error} должна быть вызвана только с одним аргументом --- условием.

Если \emph{datum} является типом условия (классом или именем класса),
используется экземпляр созданный с помощью \cd{(apply \#'make-condition
  \emph{datum} \emph{arguments})}.

Если \emph{datum} является строкой, тогда условие создаётся с помощью команды
\begin{lisp}
(make-condition 'simple-error \\*
~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
~~~~~~~~~~~~~~~~:format-arguments \emph{arguments})
\end{lisp}
\end{defun}

\begin{defun}[Функция]
cerror continue-format-string datum &rest arguments

Функция \cdf{cerror} сигнализирует условие. Если условие не было обработано,
вызывается \cd{(invoke-debugger \emph{condition})}. Во время работы механизма
сигнализирования и, одновременно, работы отладчика (если он был запущен)
существует возможность продолжения выполнения программы (то есть локального
возврата из \cdf{cerror} с помощью перезапуска \cdf{continue}.

Если аргумент \emph{datum} является условием, тогда оно и используется. 
В этом случае, список аргументов \emph{arguments} не обязан быть пустым, и
используется только для строки \emph{continue-format-string}.

Если \emph{datum} является типом условия (классом или именем класса), тогда
объект условия будет создаваться с помощью \cd{(apply \#'make-condition
  \emph{datum} \emph{arguments})}.

Если \emph{datum} является строкой, тогда создание объекта условия происходит так:
\begin{lisp}
(make-condition 'simple-error \\*
~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
~~~~~~~~~~~~~~~~:format-arguments \emph{arguments})
\end{lisp}

Аргумент \emph{continue-format-string} должен быть строкой. Необходимо отметить,
что если \emph{datum} не является строкой, тогда остальные аргументы
используются для строки форматирования \emph{continue-format-string} как обычно
(если \emph{datum} задаёт тип условия, остальные аргументы должны выглядеть как
пары: ключевой символ, значение). В этом случае для корректной установки
параметров в \emph{continue-format-string} может быть использована директива
форматирования \cd{{\Xtilde}*}, которая игнорирует и пропускает аргументы.

Функция \cdf{cerror} возвращает значение \cdf{nil}.
\end{defun}

\begin{defun}[Функция]
signal datum &rest arguments

Запускает механизм сигнализирования условия. Если условие не было обработано,
\cdf{signal} возвращает \cdf{nil}.

Если \emph{datum} является условием, тогда это условие и используется.
В этом случае аргументов \emph{arguments} быть не должно, то есть \cdf{signal}
должна быть вызвана только с одним аргументом, условием.

Если \emph{datum} является типом условия (классом или именем класса), тогда
объект условия создаётся с помощью \cd{(apply \#'make-condition \emph{datum}
  \emph{arguments})}.

Если \emph{datum} является строкой, тогда объект условия создаётся так:
\begin{lisp}
  (make-condition 'simple-error \\*
  ~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
  ~~~~~~~~~~~~~~~~:format-arguments \emph{arguments})
\end{lisp}

Необходимо отметить, что если \cd{(typep \emph{condition} *break-on-signals*)}
является истиной, тогда отладчик вступит в действие раньше процесса
сигнализирования. Для продолжения процесса сигнализирования может быть
использована функция перезапуска \cdf{continue}. Перезапуск связан с
сигнализируемым условием, как если с помощью \cdf{with-condition-restarts}.
Это верно также для всех других функций и макросов, которые сигнализируют
условия: \cdf{warn}, \cdf{error}, \cdf{cerror}, \cdf{assert} и
\cdf{check-type}.

В время динамической продолжительности вызова \cdf{signal} с некоторым условием,
результат вызова \cdf{signal} вновь с тем же объектом условия не предсказуем.
Например, не смотря на то, что обработчик \emph{может} ресигнализировать условие
для передачи его внешним обработчикам, два различных асинхронных события от
клавиатуры не могут сигнализировать одинаковые (\cdf{eq}) объекты условия в
одинаковое время.

Для подробного описания смотрите раздел~\ref{CONDITION-HANDLERS}.
\end{defun}


\begin{defun}[Переменная]
*break-on-signals*

Данная переменная используется, когда пользователь отлаживает программы, которые
сигнализируют ошибки. Значением \cd{*break-on-signals*} должно быть подходящее
значение для второго аргумента в \cdf{typep}, то есть тип или спецификатор типа.

Когда выражение \cd{(typep \emph{condition} *break-on-signals*)} истинно, тогда
вызовы функции \cdf{signal} (или других функций-обёрток над данной) будут неявно
вызывать отладчик перед сигнализированием \emph{условия}. Для продолжения
процесса сигнализирования может быть использована функция перезапуска
\cdf{continue}. Перезапуск связан с сигнализируемым условием, как если с помощью
\cdf{with-condition-restarts}.

Следует отметить, что \cdf{nil} является корректным спецификатором типа. Если
значение \cdf{*break-on-signals*} равно \cdf{nil}, тогда \cdf{signal} никогда не
вызовет отладчик в этой неявной форме.

При установке этой переменной, пользователь может выбрать наиболее специфичный
тип для перехвата. Установка этого флага нарушает модульность обработки
сигналов, В некоторых случаях это приводит к непредсказуемым последствиям, так
как пользователь может не знать количество и места вызовов \cdf{signal}.

По-умолчанию---и, конечно, в любом <<промышленном>> использовании---значением
этой переменной должно быть \cdf{nil}, как по соображениям производительности,
так и модульности и абстрагированности. 
\end{defun}


\subsection{Проверка ошибок}
\label{CONDITION-ASSERTIONS}

Данные функции используются для удобной проверки ошибок в коде.

\begin{defmac}
check-type place typespec [string]

Форма \cdf{check-type} сигнализирует ошибку типа \cdf{type-error}, если
содержимое \emph{place} не принадлежит указанному типу.

Если условие было сигнализировано, обработчики данного условия могут
использовать функции \cdf{type-error-datum} и \cdf{type-error-expected-type}
для доступа к содержимому \emph{place} и \emph{typespec}, соответственно.

Данная функция возвращает управление, только если был вызван перезапуск
\cdf{store-value} или явно из обработчика, или неявно как одна из команд
отладчика. Перезапуск связан с сигнализируемым условием, как если бы с помощью
функции \cdf{with-condition-restarts}.

Если вызывается \cdf{store-value}, \cdf{check-type} сохраняет новое значение из
аргумента \cdf{store-value} (или из пользовательского ввода в отладчике) в место
\emph{place} и заново проверяет тип нового значения и сигнализирует другую
ошибку, если тип всё ещё не удовлетворяет условию. Подформы \emph{place} могут
вычисляться много раз, потому что происходит неявный цикл
вызовов. \cdf{check-type} возвращает \cdf{nil}.

\emph{place} должен быть обобщённой переменной, которая может использоваться в
\cdf{setf}. \emph{typespec} должен быть спецификатором типа, данный аргумент не
вычисляется.  \cdf{string} должен быть описанием типа на английском,
начинающемся с артикля (<<a>> или <<an>>), данный аргумент вычисляется.  Если
аргумент \emph{string} не был указан, то он вычисляется автоматически исходя из
спецификатора \emph{typespec}. Аргумент \emph{string} предусмотрен для тех
программ, которые хотят вывести некоторую дополнительную информацию.

Сообщение об ошибке будет ссылаться на \emph{place}, его содержимое и указанный тип.

\beforenoterule
\begin{implementation}
  An implementation may choose to generate a somewhat differently worded error
  message if it recognizes that \emph{place} is of a particular form, such as
  one of the arguments to the function that called \cdf{check-type}.
\end{implementation}
\afternoterule

\begin{lisp}
Lisp> (setq aardvarks '(sam harry fred)) \\*
~\EV\ (SAM HARRY FRED) \\
Lisp> (check-type aardvarks (array * (3))) \\*
Error: The value of AARDVARKS, (SAM HARRY FRED), \\*
~~~~~~~is not a 3-long array. \\
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify a value to use instead. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 1 \\*
Use Value: \#(sam fred harry) \\*
~\EV\ NIL \\
Lisp> aardvarks \\*
~\EV\ \#<ARRAY-3 13571> \\
Lisp> (map 'list \#'identity aardvarks) \\*
~\EV\ (SAM FRED HARRY) \\
Lisp> (setq aacount 'foo) \\*
~\EV\ FOO \\
Lisp> (check-type aacount (integer 0 *) "a non-negative integer") \\*
Error: The value of AACOUNT, FOO, is not a non-negative integer. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify a value to use instead. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 2 \\*
Lisp> 
\end{lisp}
\end{defmac}

\begin{defmac}
assert test-form [({place}*) [datum {argument}*]]

Форма \cdf{assert} сигнализирует ошибку, если значение формы \emph{test-form}
равно \cdf{nil}. Исправление данной ошибки с помощью перезапуска \cdf{continue}
позволяет пользователю изменить значения некоторых переменных, и \cdf{assert}
будет вновь перепроверять \emph{test-form}. Перезапуск связан с сигнализируемым
условием, как если бы с помощью функции \cdf{with-condition-restarts}.
\cdf{assert} возвращает \cdf{nil}.

Форма \emph{test-form} может быть любой. Каждый \emph{place} (может быть любой
количество, в том числе ноль) должен быть обобщённой переменной, которая может
использоваться в \cdf{setf}. Эти переменные должны использоваться в форме
\emph{test-form}, чтобы пользователь мог попытаться изменить их во время
исправления ошибки. Подформы каждого аргумента \emph{place} вычисляются, только
если сигнализирует ошибка. Они также перевычисляются, если ошибка была
сгенерирована вновь (после коррекции, которая не привела к положительному
результату).

Аргументы \emph{datum} и \emph{argument} вычисляются, только если
сигнализируется ошибка, и перевычисляются, если ошибка сигнализируется вновь.

Если аргумент \emph{datum} является условием, то это условие и используется. В
этом случае указание других аргументов \emph{argument} является ошибкой.

Если \emph{datum} является типом условия (классом или именем класса), тогда
условие создаётся с помощью формы \cd{(apply \#'make-condition \emph{datum}
  (list \Mstar{argument}))}.

Если \emph{datum} является строкой, тогда условие создаётся так:
\begin{lisp}
(make-condition 'simple-error \\*
~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
~~~~~~~~~~~~~~~~:format-arguments (list \Mstar{argument}))
\end{lisp}

Если \emph{datum} не указан, тогда создаётся условие типа \cdf{simple-error} с
указанием \emph{test-form} в качестве данных. Например:
\begin{lisp}
(make-condition 'simple-error \\
~~:format-string "The assertion {\Xtilde}S failed." \\
~~:format-arguments '(\emph{test-form}))
\end{lisp}
Следует отметить, что \emph{test-form} для строки ошибки используется сама по
себе, а не её значение.

\beforenoterule
\begin{implementation}
  The debugger need not include the \emph{test-form} in the error message, and
  any \emph{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, an opportunity should be presented to alter the values of any or all
  of the references. The details of this depend on the implementation's style of
  user interface, of course.
\end{implementation}
\afternoterule

Простой пример использования \cdf{assert}:
\begin{lisp}
(setq x (make-array '(3 5) :initial-element 3)) \\
(setq y (make-array '(3 5) :initial-element 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 {\Xtilde}S by {\Xtilde}S." a b) \\*
~~~~(really-matrix-multiply a b))) \\
 \\
(matrix-multiply x y) \\
Error: Cannot multiply \#<ARRAY-3-5 12345> by \#<ARRAY-3-5 12364>. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify new values. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 1 \\*
Value for A: x \\*
Value for B: (make-array '(5 3) :initial-element 6) \\
~\EV \#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{lisp}
\end{defmac}

\subsection{Проверка значение на соответствие}
\label{EXHAUSTIVE-CASE-ANALYSIS-CONDITIONS}

Синтаксис для \cdf{etypecase} и \cdf{ctypecase} такой же как и для
\cdf{typecase}, за исключением отсутствия выражения \cdf{otherwise}. Аналогично,
синтаксис для \cdf{ecase} и \cdf{ccase} такой же как и для \cdf{ccase}, за
исключением выражения \cdf{otherwise}.

\cdf{etypecase} и \cdf{ecase} похожи на \cdf{typecase} и \cdf{case},
соответственно, однако, при отсутствии подходящего выражения, сигнализируют
невосстановимую ошибку вместо того, чтобы вернуть \cdf{nil}.

\cdf{ctypecase} и \cdf{ccase} также похожи на \cdf{typecase} и \cdf{case},
соответственно, и при отсутствии подходящего выражения, сигнализируют
восстановимую ошибку вместо того, чтобы вернуть \cdf{nil}.

\begin{defmac}
etypecase keyform {(type {form}*)}*

Данная управляющая конструкция похожа на \cdf{typecase}, но без явных
\cdf{otherwise} или \cdf{t} выражений. Если ни одно выражение не подошло под
условие, \cdf{ecase} сигнализирует ошибку (типа \cdf{type-error}) со строкой,
которая будет создана на основе этих выражений. Исправить данную ошибку
невозможно. Для указания сообщения, пользователь должен использовать
\cdf{typecase} с выражением \cdf{otherwise}, содержащим вызов \cdf{error}. Имя
данной функции образовано от <<exhaustive type case>> или <<error-checking type
case>>.

Например:
\begin{lisp}
Lisp> (setq x 1/3) \\*
~\EV\ 1/3 \\
Lisp> (etypecase x \\*
~~~~~~~~(integer (* x 4)) \\*
~~~~~~~~(symbol~(symbol-value x))) \\
Error: The value of X, 1/3, is neither an integer nor a symbol. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Return to Lisp Toplevel. \\*
Debug>
\end{lisp}
\end{defmac}

\begin{defmac}
ctypecase keyplace {(type {form}*)}*

Данная управляющая конструкция похожа на \cdf{typecase}, но без явных
\cdf{otherwise} или \cdf{t} выражений.

Аргумент \emph{keyplace} должен быть обобщённой переменной, которая может
использоваться в \cdf{setf}. Если ни одно выражение не соответствовало типу
\emph{keyplace}, \cdf{ctypecase} сигнализирует ошибку (типа \cdf{type-error}) с
сообщением, которое генерируется с использованием выражение. Данная ошибка может
быть исправлена с помощью перезапуска \cdf{store-value}. Аргумент
для \cdf{store-value} сохраняется в \emph{keyplace} и затем \cdf{ctypecase}
вновь проверяет тип выражения. Таким образом подформы \emph{keyplace} могут быть
выполнены несколько раз. Если перезапуск \cdf{store-value} был запущен
интерактивно, у пользователя будет запрошено новое значение.

Имя данной функции расшифровывается <<continuable (exhaustive) type
case>>.

Например:
\begin{lisp}
Lisp> (setq x 1/3) \\*
~\EV\ 1/3 \\
Lisp> (ctypecase x \\*
~~~~~~~~(integer (* x 4)) \\*
~~~~~~~~(symbol (symbol-value x))) \\
Error: The value of X, 1/3, is neither an integer nor a symbol. \\*
To continue, type :CONTINUE followed by an option number: \\
~1: Specify a value to use instead. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 1 \\*
Use value: 3.7 \\
Error: The value of X, 3.7, is neither an integer nor a symbol. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify a value to use instead. \\*
~2: Return to Lisp Toplevel. \\
Debug> :continue 1 \\*
Use value: 12 \\*
~\EV\ 48
\end{lisp}
\end{defmac}


\begin{defmac}
ecase keyform {({({key}*) | key} {form}*)}*

Данная управляющая конструкция похожа на \cdf{case}, но без явных
\cdf{otherwise} или \cdf{t} выражений. Если ни одно выражение не подошло под
условие, \cdf{ecase} сигнализирует ошибку (типа \cdf{type-error}) со строкой,
которая будет создана на основе этих выражений. Исправить данную ошибку
невозможно. Для указания сообщения, пользователь должен использовать \cdf{case}
с выражением \cdf{otherwise}, содержащим вызов \cdf{error}. Имя данной функции
образовано от <<exhaustive case>> или <<error-checking case>>.

Например:
\begin{lisp}
Lisp> (setq x 1/3) \\*
~\EV\ 1/3 \\
Lisp> (ecase x \\*
~~~~~~~~(alpha (foo)) \\*
~~~~~~~~(omega (bar)) \\*
~~~~~~~~((zeta phi) (baz))) \\
Error: The value of X, 1/3, is not ALPHA, OMEGA, ZETA, or PHI. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Return to Lisp Toplevel. \\*
Debug>
\end{lisp}
\end{defmac}

\begin{defmac}
ccase keyplace {({({key}*) | key} {form}*)}*

Данная управляющая конструкция похожа на \cdf{case}, но без явных
\cdf{otherwise} или \cdf{t} выражений.

Аргумент \emph{keyplace} должен быть обобщённой переменной, которая может
использоваться в \cdf{setf}. Если ни одно выражение не соответствовало типу
\emph{keyplace}, \cdf{ccase} сигнализирует ошибку (типа \cdf{type-error}) с
сообщением, которое генерируется с использованием выражений. Данная ошибка может
быть исправлена с помощью перезапуска \cdf{store-value}. Аргумент
для \cdf{store-value} сохраняется в \emph{keyplace} и затем \cdf{ctypecase}
вновь проверяет тип выражения. Таким образом подформы \emph{keyplace} могут быть
выполнены несколько раз. Если перезапуск \cdf{store-value} был запущен
интерактивно, у пользователя будет запрошено новое значение.

Имя функции образовано от <<continuable (exhaustive) case>>.

\beforenoterule
\begin{implementation}
  The \cdf{type-error} signaled by \cdf{ccase} and \cdf{ecase} is free to
  choose any representation of the acceptable argument type that it wishes
  for placement in the expected-type slot. It will always work to use type
  \cd{(member . \emph{keys})}, but in some cases it may be more efficient, for example,
  to use a type that represents an integer subrange or a type composed using the
  \cdf{or} type specifier.
\end{implementation}
\afternoterule
\end{defmac}

\subsection{Обработка условий}

Данные макросы позволяют программе контролировать ситуацию в случае
сигнализирования условия.

\begin{defmac}
handler-case expression {(typespec ([var]) {form}*)}*

Форма выполняет заданное выражение \emph{expression} в контексте указанных
обработчиков условий.

Каждый \emph{typespec} может быть любым спецификатором типа. Если во время
выполнения \emph{expression} было сигнализировано условие, для которого указан
соответствующий обработчик---то есть, одно из выражений \cd{(typep
  \emph{condition} '\emph{typespec})} истинно---и если внутри выражения не было
других обработчиков для этого типа условия, тогда выполнение переносится в тело
соответствующего обработчика (должным образом раскручивая
динамические состояния) и заданная переменная \emph{var} связывается с
сгенерированным объектом условия. Если условия сигнализировано не было, форма
\cdf{handler-case} возвращает значение(я) формы \emph{expression}.

Если указано более одного обработчика, то они делаются доступными
параллельно. То есть в выражении
\begin{lisp}
(handler-case \emph{expression} \\*
~~(\emph{type\SU{1}} (\emph{var\SU{1}}) \emph{form\SU{1}}) \\*
~~(\emph{type\SU{2}} (\emph{var\SU{2}}) \emph{form\SU{2}}))
\end{lisp}
если будет выбрано первое выражение (содержащие \emph{form\SU{1}}, то второй
обработчик для первого виден не будет.

Обработчики ищутся последовательно сверху вниз. Если сигнализированное условие
подходит более чем одному обработчику (возможно при пересечении типов), то
выбран будет наиболее верхний (или наиболее ранее встретившийся).

Если в переменной \emph{var} нет необходимости, она может быть опущена. То есть,
такое выражение как
\begin{lisp}
(\emph{type} (\emph{var}) (declare (ignore \emph{var})) \emph{form})
\end{lisp}
может быть записано так
\begin{lisp}
(\emph{type} () \emph{form})
\end{lisp}

Если для условия не было найдено соответствующего обработчика,
\cdf{handler-case} возвращает \cdf{nil}. Следует отметить, что 
\begin{lisp}
(handler-case \emph{expression} \\*
~~(\emph{type\SU{1}} (\emph{var\SU{1}}) . \emph{body\SU{1}}) \\*
~~(\emph{type\SU{2}} (\emph{var\SU{2}}) . \emph{body\SU{2}}) \\*
~~...)
\end{lisp}
приблизительно эквивалентно
\begin{lisp}
(block \#1=\#:block-1 \\*
~~(let (\#2=\#:var-2) \\*
~~~~(tagbody \\*
~~~~~~(handler-bind ((\emph{type\SU{1}} \=\#'(lambda (temp) \\*
\>~~~~(setq \#2\# temp) \\*
\>~~~~(go \#3=\#:tag-3))) \\
~~~~~~~~~~~~~~~~~~~~~(\emph{type\SU{2}} \=\#'(lambda (temp) \\*
\>~~~~(setq \#2\# temp) \\*
\>~~~~(go \#4=\#:tag-4))) \\*
~~~~~~~~~~~~~~~~~~~~~...) \\*
~~~~~~~~(return-from \#1\# \emph{expression})) \\
~~~~~~\#3\# (return-from \#1\# (let ((\emph{var\SU{1}} \#2\#)) . \emph{body\SU{1}})) \\*
~~~~~~\#4\# (return-from \#1\# (let ((\emph{var\SU{2}} \#2\#)) . \emph{body\SU{2}})) \\*
~~~~~~...)))
\end{lisp}
[Note the use of ``gensyms'' such as \cd{\#:block-1}
as block names, variables, and \cdf{tagbody} tags in this example,
and the use of \cd{\#\emph{n}=} and \cd{\#\emph{n}\#} read-macro syntax
to indicate that the very same gensym appears in multiple places.---GLS]

В исключительном случае в последнем обработчике спецификатор \emph{typespec} может быть символом
\cd{:no-error}. Тогда, данный обработчик получит управление, если
вычисление \emph{expression} завершилось нормально. В этом случае, после символа
\cd{:no-error} может следовать полноценный лямбда-список, и данный лямбда-список
будет связан с значениями выражения \emph{expression}, как если бы с помощью
\cdf{multiple-value-call}. Например,
\begin{lisp}
(handler-case \emph{expression} \\*
~~(\emph{type\SU{1}} (\emph{var\SU{1}}) . \emph{body\SU{1}}) \\*
~~(\emph{type\SU{2}} (\emph{var\SU{2}}) . \emph{body\SU{2}}) \\*
~~... \\*
~~(\emph{type\SU{n}} (\emph{var\SU{n}}) . \emph{body\SU{n}}) \\*
~~(:no-error (\emph{nvar\SU{1}} \emph{nvar\SU{2}} ... \emph{nvar\SU{m}}) . \emph{nbody}))
\end{lisp}
примерно эквивалентно
\begin{lisp}
(block \#1=\#:error-return \\*
~~(multiple-value-call \#'(lambda (\emph{nvar\SU{1}} \emph{nvar\SU{2}} ... \emph{nvar\SU{m}}) . \emph{nbody}) \\*
~~~~(block \#2=\#:normal-return \\*
~~~~~~(return-from \#1\# \\*
~~~~~~~~(handler-case (return-from \#2\# \emph{expression}) \\*
~~~~~~~~~~(\emph{type\SU{1}} (\emph{var\SU{1}}) . \emph{body\SU{1}}) \\*
~~~~~~~~~~(\emph{type\SU{2}} (\emph{var\SU{2}}) . \emph{body\SU{2}}) \\*
~~~~~~~~~~... \\*
~~~~~~~~~~(\emph{type\SU{n}} (\emph{var\SU{n}}) . \emph{body\SU{n}}))))))
\end{lisp}

Примеры использования \cdf{handler-case}:
\begin{lisp}
(handler-case (/ x y) \\*
~~(division-by-zero () nil)) \\
 \\
(handler-case (open *the-file* :direction :input) \\*
~~(file-error (condition) (format t "{\Xtilde}\&Fooey: {\Xtilde}A{\Xtilde}\%" condition))) \\
 \\
(handler-case (some-user-function) \\*
~~(file-error (condition) condition) \\*
~~(division-by-zero () 0) \\*
~~((or unbound-variable undefined-function) () 'unbound)) \\
 \\
(handler-case (intern x y) \\*
~~(error (condition) condition) \\*
~~(:no-error (symbol status) \\*
~~~~(declare (ignore symbol)) \\*
~~~~status))
\end{lisp}
\end{defmac}

\begin{defmac}
ignore-errors {form}*

Выполняет тело \emph{forms} при этом обрабатывая условия типа \cdf{error} тем,
что просто возвращаем управление из этой формы. Если не было сигнализировано
условий, в качестве результата выступает значение(я) последней формы. Иначе
возвращается два значения: \cdf{nil} и \cdf{error} условие, которое было
сигнализировано.

\cdf{ignore-error} может быть определено следующим образом:
\begin{lisp}
(defmacro ignore-errors (\&body forms) \\*
~~{\Xbq}(handler-case (progn ,{\Xatsign}forms) \\*
~~~~~(error (c) (values nil c))))
\end{lisp}
\end{defmac}

\begin{defmac}
handler-bind ({(typespec handler)}*) {form}*

Выполняет тело в динамическом контексте, в котором установлены заданные
обработчики. Каждый \emph{typespec} может быть любым спецификатором типа. Каждый
форма \emph{handler} должна вернуть функцию, которая будет использоваться
для обработки условия заданного типа, если такое условие будет сигнализировано в
формах \emph{form}. Эта функция должна принимать один аргумент ---
сигнализируемое условие.

Если указано более одного обработчика, то поиск подходящего осуществляется
последовательно сверху вниз (по визуальной аналогии с \cdf{typecase}). Если
соответствующий спецификатор типа \emph{typespec} найден, то связанный
обработчик выполняется в контексте, в котором больше нет обработчиков, чтобы
избежать ошибки рекурсии. Например в случае:
\begin{lisp}
(handler-bind ((unbound-variable \#'(lambda ...)) \\*
~~~~~~~~~~~~~~~(error \#'(lambda ...))) \\*
~~...)
\end{lisp}
если в теле сигнализируется ошибка <<несвязанной переменной>> (и в этом же теле
она не обрабатывается), выполняется первая функция. Если сигнализируется
какой-либо другой тип ошибки, вызывается вторая функция. В любом случае ни один
из перечисленных обработчиков не доступен в теле другого.
\end{defmac}

\subsection{Определение типов условий}

[The contents of this section are still a subject of some debate within X3J13.
The reader may wish to take this section with a grain of salt, two aspirin
tablets, and call a hacker in the morning.---GLS]

\begin{defmac}
define-condition name ({parent-type}*)
                 [({slot-specifier}*) {option}*]

Определяет новый тип условия с именем \emph{name} и родительским типом
\emph{parent-type}. Аргументы формы не вычисляются, если не указано иное.

Объекты данного типа условия будут содержать все заданные слоты \emph{slot}, а
также дополнительные слоты, унаследованные от родительских типов. Если список
слотов не указан, то используется пустой список слотов.

Аргумент \emph{slot} должен иметь форму
\begin{tabbing}
\emph{slot-specifier\/} ::= \emph{slot-name\/} {\Mor} (\emph{slot-name\/}  $\lbrack\!\lbrack\downarrow\!\emph{slot-option}\,\rbrack\!\rbrack$)
\end{tabbing}
Для синтаксиса параметра \emph{slot-option}, смотрите \cdf{defclass}.
Слоты объекта условия являются обычными CLOS слотами.
Следует отметить, что вместо функций доступа к слотам может использоваться
\cdf{with-slots}.

\cdf{make-condition} будет принимать ключевые символы (из пакета ключевых
символов) с выводимыми именами соответствующие слотам, и инициализировать
данные слоты указанными значениями.

Функции доступа к слотам (аксессоры) создаются в соответствие с теми же
правилами, как и для \cdf{defclass}.

Корректные параметры \emph{options} перечислены ниже:

\begin{flushdesc}

\item[\cd{(:documentation \emph{doc-string})}]

  \emph{doc-string} должен быть или \cdf{nil} или строкой, которая описывает
  смысл данного типа условия. Если данный параметр не указан, то используется
  значение \cdf{nil}. Для получения значения данного параметра служит форма
  \cd{(documentation '\emph{name} 'type)}

\item[\cd{(:report \emph{exp})}]

  Если \emph{exp} не является литеральной строкой, она должна быть подходящим
  аргументом для специального оператора \cdf{function}. В текущем лексическом
  окружении будет выполнено выражение \cd{(function~\emph{exp})}. Данная форма
  должна вернуть функцию двух аргументов: условия и потока, которая будет
  выводить в поток описание данного условия. Данная функция вызывается всякий
  раз, когда выводится условие, пока \cdf{*print-escape*} равно \cdf{nil}.

  Если \emph{exp} является литеральной строкой, она заменяется
  \begin{lisp}
    (lambda (c s) \\*
    ~~(declare (ignore c)) \\*
    ~~(write-string \emph{exp} s))
  \end{lisp}
  [That is, a function is provided that will simply write the given
  string literally to the stream, regardless of the particular condition object
  supplied.---GLS]
  
  Параметр \cd{:report} обрабатывается \emph{после} того, как будет создан новый
  тип условия, таким образом, в функции вывода можно использовать аксессоры
  слотов. Если данный параметр не указан, информация о том, как выводить данный
  тип условия будет унаследована от родительского типа.
  
\end{flushdesc}

Вот несколько примеров использования \cdf{define-condition}.

Следующая форма определяет тип условия \cd{peg/hole-mismatch}, который наследует
тип \cdf{blocks-world-error}:
\begin{lisp}
(define-condition peg/hole-mismatch (blocks-world-error) \\*
~~~~~~~~~~~~~~~~~~(peg-shape hole-shape) \\*
~~(:report \\
~~~~(lambda (condition stream) \\*
~~~~~~(with-slots (peg-shape hole-shape) condition \\*
~~~~~~~~(format stream "A {\Xtilde}A peg cannot go in a {\Xtilde}A hole." \\*
~~~~~~~~~~~~~~~~peg-shape hole-shape))))
\end{lisp}
Новый тип содержит слоты \cdf{peg-shape} и \cdf{hole-shape}, таким
\cdf{make-condition} будет принимать именованные параметры \cd{:peg-shape} и
\cd{:hole-shape}. Как показано в \cd{:report}, для доступа к слотам
\cdf{peg-shape} и\cdf{hole-shape} может использовать макрос \cdf{with-slots}.

Вот другой пример. В нем определяется условие \cdf{machine-error} унаследованное
от \cdf{error}:
\begin{lisp}
(define-condition machine-error (error) \\*
~~~~~~~~~~~~~~~~~~((machine-name \\*
~~~~~~~~~~~~~~~~~~~~:reader machine-error-machine-name)) \\
~~(:report (lambda (condition stream) \\*
~~~~~~~~~~~~~(format stream "There is a problem with {\Xtilde}A." \\*
~~~~~~~~~~~~~~~~~~~~~(machine-error-machine-name condition)))))
\end{lisp}
После выполнения этой формы, мы можем определить новый тип ошибки, которые будет
являться подтипом \cdf{machine-error} для использования когда компьютер не доступен:
\begin{lisp}
(define-condition machine-not-available-error (machine-error) () \\*
~~(:report (lambda (condition stream) \\*
~~~~~~~~~~~~~(format stream "The machine {\Xtilde}A is not available." \\*
~~~~~~~~~~~~~~~~~~~~~(machine-error-machine-name condition)))))
\end{lisp}
Теперь можно определить ещё более специфичный тип условия, который содержит для
слота \cd{machine-name} значение по-умолчанию.
\begin{lisp}
(define-condition my-favorite-machine-not-available-error \\*
~~~~~~~~~~~~~~~~~~(machine-not-available-error) \\*
~~~~~~~~~~~~~~~~~~((machine-name :initform "MC.LCS.MIT.EDU")))
\end{lisp}
Следует отметить, что параметр \cd{:report} не был указан, поэтому способ вывода
объекта условия будет унаследован от \cdf{machine-not-available-error}.
\end{defmac}

\subsection{Создание условий}

Для создания объектов условий используется функция \cdf{make-condition}.

\begin{defun}[Функция]
make-condition type &rest slot-initializations

Создаёт объект условия заданного типа \emph{type} с использованием значений для
слотов из \emph{slot-initializations}. Функция возвращает созданный объект.

Аргументы \emph{slot-initializations} представлены в виде пар: ключевой символ,
значение. Например:
\begin{lisp}
(make-condition 'peg/hole-mismatch \\*
~~~~~~~~~~~~~~~~:peg-shape 'square :hole-shape 'round)
\end{lisp}
\end{defun}

\subsection{Установка перезапусков}

Базовая форма, которая создаёт точки перезапусков, называется
\cdf{restart-bind}.  Макрос \cdf{restart-case} является абстракцией, которая
решает большинство задач \cdf{restart-bind}, и имеет более приятный
синтаксис. Смотрите также \cdf{with-simple-restart}.  Функция, которая
передаёт управление в точку перезапуска, установленную одним из этих макросов,
называется \cdf{invoke-restart}.

Все перезапуски имеют динамическую продолжительность видимости. Перезапуск не
оставляет в живых форму, которая его установила.

\begin{defmac}
with-simple-restart (name format-string {format-argument}*)
                    {form}*

Это сокращение для одного из наиболее распространённых применений
\cdf{restart-case}.

Если перезапуск с именем \emph{name} во время исполнения форм \emph{form} не
вызывался, то \emph{with-simple-restart} возвращает все значения, которые
вернула последняя форма \emph{form}. Если перезапуск запускался, управление
передаётся в форму \cdf{with-simple-restart}, которая немедленно возвращает
два значения \cdf{nil} и \cdf{t}.

Аргумент \emph{name} может быть \cdf{nil}. В этом случае устанавливается
анонимный перезапуск.

\cdf{with-simple-restart} может быть определён так
\begin{lisp}
(defmacro with-simple-restart ((restart-name format-string \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\&rest format-arguments) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\&body forms) \\
~~{\Xbq}(restart-case (progn ,{\Xatsign}forms) \\*
~~~~~(,restart-name () \\*
~~~~~~~:report \\*
~~~~~~~~~(lambda (stream) \\*
~~~~~~~~~~~(format stream format-string ,{\Xatsign}format-arguments)) \\*
~~~~~~~(values nil t))))
\end{lisp}

Пример использования \cdf{with-simple-restart}.
\begin{lisp}
Lisp> (defun read-eval-print-loop (level) \\*
~~~~~~~~(with-simple-restart \\*
~~~~~~~~~~~~(abort "Exit command level {\Xtilde}D." level) \\*
~~~~~~~~~~(loop \\*
~~~~~~~~~~~~(with-simple-restart \\*
~~~~~~~~~~~~~~~~(abort "Return to command level {\Xtilde}D." level) \\*
~~~~~~~~~~~~~~(let ((form (prog2 (fresh-line) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(read) \\*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(fresh-line)))) \\*
~~~~~~~~~~~~~~~~(prin1 (eval form))))))) \\*
~\EV\ READ-EVAL-PRINT-LOOP \\
Lisp> (read-eval-print-loop 1) \\*
(+ 'a 3) \\
Error: The argument, A, to the function + was of the wrong type. \\*
~~~~~~~The function expected a number. \\*
To continue, type :CONTINUE followed by an option number: \\*
~1: Specify a value to use this time. \\*
~2: Return to command level 1. \\*
~3: Exit command level 1. \\*
~4: Return to Lisp Toplevel. \\*
Debug> 
\end{lisp}

\beforenoterule
\begin{sideremark}
Some readers may wonder what ought to be done by the ``abort'' key (or whatever
the implementation's interrupt key is---Control-C or Control-G, for
example). Such interrupts, whether synchronous or asynchronous in nature, are
beyond the scope of this chapter and indeed are not currently addressed by
Common Lisp at all. This may be a topic worth standardizing under separate
cover. Here is some speculation about some possible things that might happen.

An implementation might simply call \cdf{abort} or \cdf{break} directly without
signaling any condition.

Another implementation might signal some condition related to the fact that a
key had been pressed rather than to the action that should be taken. This is one
way to allow user customization.  Perhaps there would be an
implementation-dependent \cdf{keyboard-interrupt} condition type with a slot
containing the key that was pressed---or perhaps there would be such a condition
type, but rather than its having slots, different subtypes of that type with
names like \cdf{keyboard-abort}, \cdf{keyboard-break}, and so on might be
signaled. That implementation would then document the action it would take if
user programs failed to handle the condition, and perhaps ways for user programs
to usefully dismiss the interrupt.
\end{sideremark}
\betweennoterule
\begin{implementation}
Implementors are encouraged to make sure that there is always a restart named
\cdf{abort} around any user code so that user code  can call \cdf{abort} at any
time and expect something reasonable to happen; exactly what the reasonable
thing is may vary somewhat. Typically, in an interactive program, invoking
\cdf{abort} should return the user to top level, though in some batch or
multi-processing situations killing the running process might be more
appropriate.
\end{implementation}
\afternoterule
\end{defmac}

\begin{defmac}
restart-case expression {(case-name arglist
                         {keyword value}*
                         {form}*)}*

Аргумент \emph{expression} вычисляется в динамическом контексте, в котором
выражения рассматриваются как точки, в которые может быть передано
управление. Если \emph{expression} завершает выполнение и возвращает некоторые
значения, все эти значения просто возвращаются из формы \cdf{restart-case}. При
выполнении \emph{expression}, любой код может передать управление в одно из
выражений (смотрите \cdf{invoke-restart}). Если передача состоялась, формы из
тела данного выражения будут вычислены и значения последней из них станут
результатом формы \cdf{restart-case}.

Как частный случай, если \emph{expression} является списком, в котором
\emph{car} равен \cdf{signal}, \cdf{error}, \cdf{cerror} или \cdf{warn}, тогда
\cdf{with-condition-restarts} неявно используется для связывания перезапусков с
сигнализируемым условием. Например,
\begin{lisp}
(restart-case (signal weird-error) \\*
~~(become-confused ...) \\*
~~(rewind-line-printer ...) \\*
~~(halt-and-catch-fire ...))
\end{lisp}
эквивалентно
\begin{lisp}
(restart-case (with-condition-restarts \\*
~~~~~~~~~~~~~~~~weird-error  \\*
~~~~~~~~~~~~~~~~(list (find-restart 'become-confused)  \\*
~~~~~~~~~~~~~~~~~~~~~~(find-restart 'rewind-line-printer) \\*
~~~~~~~~~~~~~~~~~~~~~~(find-restart 'halt-and-catch-fire)) \\*
~~~~~~~~~~~~~~~~(signal weird-error)) \\
~~(become-confused ...) \\*
~~(rewind-line-printer ...) \\*
~~(halt-and-catch-fire ...))
\end{lisp}

Если форм \emph{form} в выбранном выражении нет, \cdf{restart-case} просто
возвращает \cdf{nil}.

\emph{case-name} может быть \cdf{nil} или символом, который именует перезапуск.

Возможно использовать более одного выражения с одинаковым именем
\emph{case-name}. В этом случае, \cdf{find-restart} вернёт первое выражение с
этим именем. Остальные выражения доступны с помощью \cdf{compute-restarts}.

Каждый аргумент \emph{arglist} является обычным лямбда-списком содержащим
параметры для связываний в которых будет выполнены формы \emph{form}. Данные
параметры используются для передачи любых необходимых данных из вызова
\cdf{invoke-restart} в выражение \cdf{restart-case}.

По-умолчанию, \cdf{invoke-restart-interactively} будет вызывать перезапуски без
аргументов и все параметры должны быть необязательными для связи с интерактивным
перезапуском. Однако, параметры параметры могут быть обязательными, если
ключевой символ \cd{:interactive} будет использоваться для указания
\cdf{invoke-restart-interactively} о том, как вычислить необходимый список
аргументов.

Доступные пары \emph{keyword value} перечислены ниже:
\begin{flushdesc}

\item[\cd{:test \emph{fn}}]

  Аргумент \emph{fn} должен быть подходящим аргументом для специального
  оператора \cdf{function}.
  Выражение \cd{(function~\emph{fn})} будет вычислено в текущем лексическом
  окружении. Оно должно вернуть функцию одного аргумента: условия. Если
  полученная функция возвращает \cdf{nil} для заданного условия, функции
  \cdf{find-restart}, \cdf{compute-restart} и \cdf{invoke-restart} при поиске
  данных перезапуск рассматривать не будут. Если эта пара не указана, то
  используется значение по-умолчанию
  \begin{lisp}
    (lambda (c) (declare (ignore c)) t)
  \end{lisp}

\item[\cd{:interactive \emph{fn}}]

  Аргумент \emph{fn} должен быть подходящим аргументом для специального
  оператора \cdf{function}.
  Выражение \cd{(function~\emph{fn})} будет вычислено в текущем лексическом
  окружении. Оно должно вернуть функцию без аргументов, которая возвращает
  аргументы, которые используются \cdf{invoke-restart-interactively} при вызове
  данной функции. Эта функция будет вызываться в динамическом окружении
  доступном при любой попытке перезапуска.
  Если необходимо функция может интерактивно запрашивать значения с
  использованием \cdf{*query-io*}.

  Если перезапуск был вызван интерактивно, но параметр \cd{:interactive} не был
  указан, список аргументов будет пустым.

\item[\cd{:report \emph{exp}}]

  Если выражение \emph{exp} не является литеральной строкой, оно должно быть
  подходящим аргументом для специального оператора \cdf{function}. Выражение
  \cd{(function~\emph{exp})} будет вычисляться в текущем лексическом
  окружении. Оно должно вернуть функцию одного аргумента: потока, которая
  выводит в данный поток описание определяемого перезапуска. Полученная функция
  вызывается каждый раз при выводе перезапуска при \cdf{*print-escape*} равном
  \cdf{nil}.

  Если \emph{exp} является литеральной строкой, то используется следующая
  функция:
  \begin{lisp}
    (lambda (s) (write-string \emph{exp} s))
  \end{lisp}

  Если именованный перезапуск должен быть выведен, но доступной о нём информации
  нет, тогда используется его имя в умолчательном выводимом тексте.

  When \cdf{*print-escape*} is \cdf{nil}, the printer will use the report
  information for a restart. For example, a debugger might announce the action
  of typing ``\cd{:continue}'' by executing the equivalent of
  \begin{lisp}
    (format *debug-io* "{\Xtilde}\&{\Xtilde}S -- {\Xtilde}A{\Xtilde}\%" ':continue some-restart)
  \end{lisp}
  which might then display as something like
  \begin{lisp}
    :CONTINUE -- Return to command level.
  \end{lisp}
 
  Указание анонимного перезапуска и отсутствие информации о нём является ошибкой.
\beforenoterule
\begin{rationale}
Unnamed restarts are required to have report information on
the grounds that they are generally only useful interactively, and an
interactive option that has no description is of little value.
\end{rationale}
\betweennoterule
\begin{implementation}
Implementations are encouraged to warn about this error
at compilation time.

At run time, 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, and so on), it is suggested that the
debugger print some indication of such problems when they occur, but not
actually signal errors.
\end{implementation}
\afternoterule

\end{flushdesc}
Следует отметить, что 
\begin{lisp}
(restart-case \emph{expression} \\*
~~(\emph{name\SU{1}} \emph{arglist\SU{1}} \emph{options\SU{1}} . \emph{body\SU{1}}) \\*
~~(\emph{name\SU{2}} \emph{arglist\SU{2}} \emph{options\SU{2}} . \emph{body\SU{2}}) \\*
~~...)
\end{lisp}
в сущности эквивалентно
\begin{lisp}
(block \#1=\#:block-1 \\*
~~(let ((\#2=\#:var-2 nil)) \\*
~~~~(tagbody \\*
~~~~~~(restart-bind ((\emph{name\SU{1}} \=\#'(lambda (\&rest temp) \\*
\>~~~~(setq \#2\# temp) \\*
\>~~~~(go \#3=\#:tag-3)) \\*
\>\textrm{$\langle$slightly transformed \emph{options\SU{1}}$\rangle$}) \\
~~~~~~~~~~~~~~~~~~~~~(\emph{name\SU{2}} \=\#'(lambda (\&rest temp) \\*
\>~~~~(setq \#2\# temp) \\*
\>~~~~(go \#4=\#:tag-4)) \\*
\>\textrm{$\langle$slightly transformed \emph{options\SU{2}}$\rangle$}) \\*
~~~~~~~~~~~~~~~~~~~~~...) \\*
~~~~~~~~(return-from \#1\# expression)) \\
~~~~~~\#3\# (return-from \#1\# \\*
~~~~~~~~~~~~~~~~(apply \#'(lambda \emph{arglist\SU{1}} . \emph{body\SU{1}}) \#2\#)) \\
~~~~~~\#4\# (return-from \#1\# \\*
~~~~~~~~~~~~~~~~(apply \#'(lambda \emph{arglist\SU{2}} . \emph{body\SU{2}}) \#2\#)) \\*
~~~~~~...)))
\end{lisp}
[Note the use of ``gensyms'' such as \cd{\#:block-1} as block names,
variables, and \cdf{tagbody} tags in this example,
and the use of \cd{\#\emph{n}=} and \cd{\#\emph{n}\#} read-macro syntax
to indicate that the very same gensym appears in multiple places.---GLS]

Несколько примеров использования \cdf{restart-case}.
\begin{lisp}
(loop \\*
~~(restart-case (return (apply function some-args)) \\*
~~~~(new-function (new-function) \\*
~~~~~~~~:report "Use a different function." \\*
~~~~~~~~:interactive \\*
~~~~~~~~~~(lambda () \\*
~~~~~~~~~~~~(list (prompt-for 'function "Function: "))) \\*
~~~~~~(setq function new-function)))) \\
 \\
(loop \\*
~~(restart-case (return (apply function some-args)) \\*
~~~~(nil (new-function) \\*
~~~~~~~~:report "Use a different function." \\*
~~~~~~~~:interactive \\*
~~~~~~~~~~(lambda () \\*
~~~~~~~~~~~~(list (prompt-for 'function "Function: "))) \\*
~~~~~~(setq function new-function)))) \\
 \\
(restart-case (a-command-loop) \\*
~~(return-from-command-level () \\*
~~~~~~:report \\*
~~~~~~~~(lambda (s)~~~~~;\textrm{Argument \cdf{s} is a stream} \\*
~~~~~~~~~~(format s "Return from command level {\Xtilde}D." level)) \\*
~~~~nil)) \\
 \\
(loop  \\*
~~(restart-case (another-random-computation) \\*
~~~~(continue () nil)))
\end{lisp}
Первый и второй пример эквивалентны если рассматривать их с точки зрения
интерактивной отладки, но они отличаются в одном важном аспекте в
неинтерактивной обработке. Если обработчик <<знает о>> именованных перезапусках,
как например в:
\begin{lisp}
(when (find-restart 'new-function) \\*
~~(invoke-restart 'new-function the-replacement))
\end{lisp}
тогда только первый пример будет содержать передачу управления в корректирующее
выражение, так как только первый пример использует перезапуск с именем
\cdf{new-function}.

Более полный пример:
\begin{lisp}
(let ((my-food 'milk) \\*
~~~~~~(my-color 'greenish-blue)) \\*
~~(do () \\*
~~~~~~((not (bad-food-color-p my-food my-color))) \\*
~~~~(restart-case (error 'bad-food-color \\*
~~~~~~~~~~~~~~~~~~~~~~~~~:food my-food :color my-color) \\*
~~~~~~(use-food (new-food) \\*
~~~~~~~~~~:report "Use another food." \\*
~~~~~~~~(setq my-food new-food)) \\
~~~~~~(use-color (new-color) \\*
~~~~~~~~~~:report "Use another color." \\*
~~~~~~~~(setq my-color new-color)))) \\*
~~;; We won't get to here until MY-FOOD \\*
~~;; and MY-COLOR are compatible. \\*
~~(list my-food my-color))
\end{lisp}
Предполагая, что \cdf{use-food} и \cdf{use-color} были определены так:
\begin{lisp}
(defun use-food (new-food) \\*
~~(invoke-restart 'use-food new-food)) \\
\\
(defun use-color (new-color) \\*
~~(invoke-restart 'use-color new-color))
\end{lisp}
затем обработчик может исправить ошибку одним из способов. Может исправить color
или исправить food. Например:
\begin{lisp}
\#'(lambda (c) ... (use-color 'white) ...)~~~;\textrm{Corrects \cdf{color}} \\
\\
\#'(lambda (c) ... (use-food 'cheese) ...)~~~;\textrm{Corrects \cdf{food}}
\end{lisp}

Пример использования \cdf{handler-bind} и \cdf{restart-case}, который ссылается
на тип условия \cdf{foo-error}, который был определён ранее.
\begin{lisp}
(handler-bind ((foo-error \#'(lambda (ignore) (use-value 7)))) \\*
~~(restart-case (error 'foo-error) \\*
~~~~(use-value (x) (* x x)))) \\*
~\EV\ 49
\end{lisp}
\end{defmac}


\begin{defmac}
restart-bind ({(name function {keyword value}*)}*) {form}*

Выполняет формы тела в динамическом контексте, в котором установлены заданные
перезапуски.

Любое имя перезапуска \emph{name} может быть символом \cdf{nil}, указывая на
анонимный перезапуск, или любым другим символом, указывая на именованный
перезапуск.

Каждый аргумент \emph{function} является формой, которая должна вернуть функцию,
которая будет использоваться для выполнения перезапуска. Будучи вызванной, эта
функция может либо выполнить нелокальную передачу управления, либо нормально
завершиться. Функция может принимать столько аргументов, сколько программист
сочтёт нужным указать. Она будет вызвана, только если в программе используется
\cdf{invoke-restart}, или если пользователь интерактивно указывает отладчику
запустить её. В случае интерактивного вызова, используется параметр
\cd{:interactive-function}.

Возможные пары \emph{keyword value} перечислены ниже:
\begin{flushdesc}

\item[\cd{:test-function \emph{form}}]
  Форма \emph{form} будет вычислена в текущем лексическом окружении и должна вернуть
  функцию одного аргумента: условия. Если при получении аргумента эта функция
  возвращает \cdf{nil}, такие функции как \cdf{find-restart},
  \cdf{compute-restart} и \cdf{invoke-restart} не рассматривают данный
  перезапуск, при поиске по заданному условию. Если эта пара не указана, то
  используется значение по-умолчанию
  \begin{lisp}
    \#'(lambda (c) (declare (ignore c)) t)
  \end{lisp}

\item[\cd{:interactive-function \emph{form}}]

  Форма \emph{form} будет вычислена в текущем лексическом окружении и должна
  возвращать функцию без аргументов, которая создаёт список аргументов для
  использования в \cdf{invoke-restart-interactively}, при запуске данного
  перезапуска. Если необходимо функция может интерактивно запрашивать значения с
  использованием \cdf{*query-io*}.

\item[\cd{:report-function \emph{form}}]

  Форма \emph{form} будет вычислена в текущем лексическом окружении и должна
  возвращать функцию одного аргумента: потока, которая должна выводить в данный
  поток информацию о действиях данного перезапуска. Данная функция вызывается
  всякий раз при выводе перезапуска, при \cdf{*print-escape*} равном \cdf{nil}.
\end{flushdesc}
\end{defmac}

\begin{defmac}
with-condition-restarts condition-form restarts-form
  {declaration}* {form}*

Значение \emph{condition-form} должно быть условием \emph{C} и значение
\emph{restarts-form} должно быть списком перезапусков \cd{(\emph{R1} \emph{R2}
...)}. Формы тела \emph{form} вычисляются как неявный \cdf{progn}. 
Во время динамического контекста тела попытка найти перезапуск, связанный с
конкретным условием $C'$, будет рассматривать перезапуски \emph{R1}, \emph{R2},
$\ldots$, если $C'$ равен \cdf{eq} \emph{С}.

Обычно этот макрос не используется в коде явно, потому что \cdf{restart-case}
предоставляет решение для наиболее частых задач, имея при этом более краткий
синтаксис.
\end{defmac}

\subsection{Поиск и управление перезапусками}

Следующие функции определяют и вызывают активные перезапуски.

\begin{defun}[Функция]
compute-restarts &optional condition

Использует динамическое состояние программы для вычисления списка перезапусков,
которые в данный момент активны.

Если аргумент \emph{condition} не указан или равен \cdf{nil}, рассматриваются
только внешние перезапуски. Если аргумент \emph{condition} не равен \cdf{nil},
рассматриваются только перезапуски связанные с данным условием.

Каждый перезапуск представляет функцию, которая может быть вызвана для
выполнения некоторых форм, исправляющих ситуацию, обычно передавая управление во
внешнюю точку в запущенной программе. Реализации могут создавать эти объекты как
им наиболее удобно. Эти объекты нуждаются только в динамической
продолжительности видимости (относительно области формы связывания, которая их
создала).

Полученный от \cdf{compute-restarts} список отсортирован так, что внутренние (то
есть, ранее установленные) перезапуски находятся ближе к началу списка.

Также отмечается, что \cdf{compute-restarts} возвращает все корректные
перезапуски, включая анонимные, даже если некоторые из них имеют одинаковые
имена и не могли бы быть найдены с помощью \cdf{find-restarts}.

Реализация может, но не обязательно, в одинаковых окружениях возвращать разные
(то есть не равные \cdf{eq}) списки для повторяющихся вызовов
\cdf{compute-restarts}. Модификация списка, возвращённого функцией, является
ошибкой.
\end{defun}


\begin{defun}[Функция]
restart-name restart

Возвращает имя заданного перезапуска \emph{restart} и \cdf{nil}, если у
перезапуска нет имени.
\end{defun}

\begin{defun}[Функция]
find-restart restart-identifier &optional condition

Ищет конкретный перезапуск в текущем динамическом окружении.

Если аргумент \emph{condition} не указан или равен \cdf{nil}, рассматриваются
только внешние перезапуски. Если аргумент \emph{condition} не равен \cdf{nil},
рассматриваются только перезапуски связанные с данным условием.

Если аргумент \emph{restart-identifier} является не-\cdf{nil} символом, тогда
возвращается самый внутренний (то есть установленный наиболее поздно) перезапуск
с этим именем. Если перезапуск не был найден возвращается \cdf{nil}.

Если \emph{restart-identifier} является объектом перезапуска, тогда, если он
активен, то он и возвращается. Иначе возвращается \cdf{nil}.

Несмотря на то, что анонимные перезапуски именуются символом \cdf{nil}, передача
данного символа в аргументе \emph{restart-identifier} является
ошибкой. Приложения, которые так делают, должны быть переписаны с использованием
\cdf{compute-restarts}.
\end{defun}

\begin{defun}[Функция]
invoke-restart restart-identifier &rest arguments

Вызывает функцию связанную с заданным перезапуском \emph{restart-identifier}, и
передаёт в неё остальные аргументы \emph{arguments}. Аргумент
\emph{restart-identifier} должен быть перезапуском или не-null именем
перезапуска, который доступен в данном динамическом контексте.

\beforenoterule
\begin{implementation} 
Функции перезапуска вызывают эту функцию, а не наоборот.
\end{implementation} 
\afternoterule
\end{defun}

\begin{defun}[Функция]
invoke-restart-interactively restart-identifier

Вызывает функцию, связанную с заданным идентификатором перезапуска
\emph{restart-identifier}, запрашивая при этом необходимые
аргументы. \emph{restart-identifier} должен быть перезапуском или не-null именем
перезапуска, доступное в текущем динамическом контексте. Если аргумент не
корректен, сигнализируется ошибка типа \cdf{control-error}.

Функция \cdf{invoke-restart-interactively} запрашивает аргументы с помощью кода
указанного в \cd{:interactive} в \cdf{restart-case} или
\cd{:interactive-function} в \cdf{restart-bind}.

Если в соответствующей форме \cdf{restart-case} или \cdf{restart-bind} не были
указаны параметры \cd{:interactive} или \cd{:interactive-function}, тогда если
перезапуск требует обязательных аргументов, это является ошибкой. В случае если
все аргументы необязательные, будет использоваться пустой список аргументов.

После того как \cdf{invoke-restart-interactively} получила аргумент, она
выполняет форму \cd{(apply~\#'invoke-restart \emph{restart-identifier}
\emph{arguments})}.

\cdf{invoke-restart-interactively} используется внутри отладчика и может быть
полезной при реализации других переносимых отладочных инструментов.
\end{defun}

\subsection{Предупреждения}
\label{WARNING-CONDITIONS}

Предупреждения являются подклассом ошибок, которые условно называются <<мягкими>>.

\begin{defun}[Функция]
warn datum &rest arguments

Предупреждает о ситуации с помощью сигнализирования условия типа \cdf{warning}.

Если \emph{datum} является условием, тогда это условие и используется. В этом
случае, если условие не принадлежит типу \cdf{warning} или аргументы
не равны \cdf{nil}, сигнализируется ошибка типа \cdf{type-error}.

Если \emph{datum} является типом условия (классом или именем класса), тогда
условие создаётся с помощью формы \cd{(apply \#'make-condition \emph{datum}
\emph{arguments})}. Результат должен принадлежать типу \cdf{warning}, иначе
будет сигнализирована ошибка типа \cdf{type-error}.

Если \emph{datum} является строкой, тогда условие создаётся с помощью формы 
\begin{lisp}
(make-condition 'simple-error \\*
~~~~~~~~~~~~~~~~:format-string \emph{datum} \\*
~~~~~~~~~~~~~~~~:format-arguments \emph{arguments})
\end{lisp}
Точный механизм для предупреждения заключается в следующем.
\begin{enumerate}
\item Сигнализируется предупреждение.
  
  В то время как сигнализируется условие \cdf{warning}, устанавливается
  \cdf{muffle-warning} для использования обработчика для последующего перехвата
  \cdf{warn} (то есть, заставляя \cdf{warn} немедленно возвращать \cdf{nil}) 

  В рамках процесса сигнализирования, если \cd{(typep \emph{condition}
    *break-on-signals*)} является истиной, тогда \cdf{break} будет происходить
  до начала процесса сигнализирования.

\item Если для предупреждения не найдены обработчики, или если все обработчики
  неактивны, тогда условие выводится в \cdf{*error-output*} с помощью функции
  \cdf{warn}.

\item Если \cdf{warn} по-обычному возвращает управление, то её значением
  является \cdf{nil}.

\end{enumerate}
\end{defun}

\subsection{Функции перезапусков}

Common Lisp содержит следующие встроенные функции перезапусков.

\begin{defun}[Функция]
abort &optional condition

Данная функция передаёт управление в перезапуск с именем \cdf{abort}. Если
данного перезапуска нет, \cdf{continue} возвращает \cdf{nil}.

Если аргумент \emph{condition} не указан или равен \cdf{nil}, рассматриваются
только внешние перезапуски. Если аргумент \emph{condition} не равен \cdf{nil},
рассматриваются только перезапуски связанные с данным условием.
\end{defun}

\begin{defun}[Функция]
continue &optional condition

Данная функция передаёт управление в перезапуск с именем \cdf{continue}. Если
данного перезапуска нет, \cdf{continue} возвращает \cdf{nil}.

Если аргумент \emph{condition} не указан или равен \cdf{nil}, рассматриваются
только внешние перезапуски. Если аргумент \emph{condition} не равен \cdf{nil},
рассматриваются только перезапуски связанные с данным условием.

Перезапуск \cdf{continue} является частью простого протокола, в котором
существует единственный <<очевидный>> способ продолжить выполнение программы,
как в \cdf{break} и \cdf{cerror}. Некоторые определённые пользователем протокол
по схожим причинам могут также хотеть включить его. В целом, однако, более
удобно определить свой специальный перезапуск с некоторым именем, которое более
подходит для данного приложения.
\end{defun}

\begin{defun}[Функция]
muffle-warning &optional condition

Данная функция передаёт управление (а также одно значение) в перезапуск с
именем \cdf{muffle-warning}. Если данного перезапуска нет, \cdf{muffle-warning}
сигнализирует ошибку \cdf{control-error}.

Если аргумент \emph{condition} не указан или равен \cdf{nil}, рассматриваются
только внешние перезапуски. Если аргумент \emph{condition} не равен \cdf{nil},
рассматриваются только перезапуски связанные с данным условием.

\cdf{warn} устанавливает данный перезапуск, таким образом, что обработчики
условий \cdf{warning} могут сообщить функции \cdf{warn}, что \cdf{warning} уже
быть обработана, и что никакие дальнейшие действия не требуются.
\end{defun}

\begin{defun}[Функция]
store-value value &optional condition

Данная функция передаёт управление (а также одно значение) в перезапуск с
именем \cdf{store-value}. Если данного перезапуска нет, \cdf{store-value}
возвращает \cdf{nil}.

Если аргумент \emph{condition} не указан или равен \cdf{nil}, рассматриваются
только внешние перезапуски. Если аргумент \emph{condition} не равен \cdf{nil},
рассматриваются только перезапуски связанные с данным условием.

Перезапуск \cdf{use-value} обычно используется обработчиками, которые пытаются
восстановить ситуацию из ошибок таких типов, как \cdf{cell-error} или
\cdf{type-error}, и обработчик может захотеть указать новое значение для
\emph{datum} для постоянного использования.
\end{defun}

\begin{defun}[Функция]
use-value value &optional condition

Данная функция передаёт управление (а также одно значение) в перезапуск с
именем \cdf{use-value}. Если такого перезапуска нет, \cdf{use-value} возвращает
\cdf{nil}.

Если аргумент \emph{condition} не указан или равен \cdf{nil}, рассматриваются
только внешние перезапуски. Если аргумент \emph{condition} не равен \cdf{nil},
рассматриваются только перезапуски связанные с данным условием.

Перезапуск \cdf{use-value} обычно используется обработчиками, которые пытаются
восстановить ситуацию из ошибок таких типов, как \cdf{cell-error}, и обработчик
может захотеть указать новое значение для \emph{datum} для использования
единожды.
\end{defun}

\subsection{Отладочные утилиты}
\label{DEBUGGING-UTILITIES}

Common Lisp явно не указывает, что из себя представляет отладчик и что он должен
делать, но содержит необходимые вещи, которые передачи выполнения в и из
супервизор(а) и отладчик(а).

\begin{defun}[Функция]
break &optional format-string &rest format-arguments

Функция \cdf{break} выводит сообщение с помощью форматирующей строки и
аргументов: \emph{format-string} и \emph{format-arguments}, и затем без
возможности обработать ошибку вызывает отладчик.

Если \emph{format-string} не указана, будет использована строка по-умолчанию.

Если выполнение продолжится, \cdf{break} вернёт \cdf{nil}.

Следует отметить, что \cdf{break} предполагается как метод для вставки в
программу временных отладочных <<точек останова>>, а не как способ
сигнализирования ошибок. Предполагается, что в результате продолжения выполнения
из \cdf{break}, каких-либо необычных восстановительных действий не
будет. Поэтому, \cdf{break} не принимает дополнительную форматирующую строку,
как это делает \cdf{cerror} в первом аргументе.

Это и отсутствие возможности перехвата запрограммированных обработчиков ошибок
являются единственных видимым для программы различием между \cdf{break} и
\cdf{cerror}. Аспекты пользовательского интерфейса данных функций могут
отличаться более широко, например, допустимо с помощью \cdf{break}, а не с
помощью обычного отладчика, попасть в цикл чтение-выполнение-вывод
(read-eval-print loop, REPL).

\cdf{break} может быть определена как
\begin{lisp}
(defun break (\&optional (format-string "Break") \\*
~~~~~~~~~~~~~~\&rest format-arguments) \\*
~~(with-simple-restart (continue "Return from BREAK.") \\*
~~~~(invoke-debugger \\*
~~~~~~(make-condition 'simple-condition \\*
~~~~~~~~~~~~~~~~~~~~~~:format-string format-string \\*
~~~~~~~~~~~~~~~~~~~~~~:format-arguments format-arguments))) \\*
~~nil)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
invoke-debugger condition

Функция делает попытку обработать условие, которое должно быть передано в аргументе.

Если переменная \cdf{*debugger-hook*} не равна \cdf{nil}, то она будет вызвана с
двумя аргументами: объектом условия условия \emph{condition} и значением
\cdf{*debugger-hook*}. Если функция-ловушка по-обычному вернула управление,
тогда запускается стандартный отладчик.

Стандартный отладчик никогда не возвращает управление по-обычному. Возврат
осуществляется только с помощью специальной передачи управления, как например,
перезапуск.

\beforenoterule
\begin{sideremark} 
The exact way in which the debugger interacts with users is
expected to vary considerably from system to system. For example, some systems
may use a keyboard interface, while others may use a mouse interface. Of those
systems using keyboard commands, some may use single-character commands and
others may use parsed line-at-a-time commands. The exact set of commands will
vary as well. The important properties of a debugger are that it makes
information about the error accessible and that it makes the set of apparent
restarts easily accessible.

It is desirable to have a mode where the debugger allows other features, such as
the ability to inspect data, stacks, etc. However, it may sometimes be
appropriate to have this kind of information hidden from users. Experience on
the Lisp Machines has shown that some users who are not programmers develop a
terrible phobia of debuggers. The reason for this usually may be traced to the
fact that the debugger is very foreign to them and provides an overwhelming
amount of information of interest only to programmers. With the advent of
restarts, there is a clear mechanism for the construction of ``friendly''
debuggers. Programmers can be taught how to get to the information they need for
debugging, but it should be possible to construct user interfaces to the
debugger that are natural, convenient, intelligible, and friendly even to
non-programmers.
\end{sideremark}
\afternoterule
\end{defun}

\begin{defun}[Переменная]
*debugger-hook*

Данная переменная должна содержать или \cdf{nil}, или функцию двух аргументов, в
которых будет передаваться: условие и значение \cdf{*debugger-hook*}. Данная
функция может либо обработать условие (с помощью передачи управления) или
по-обычному завершится (вернуть управление, тем самым позволяя запустить
стандартный отладчик).

Следует отметить, что для уменьшения ошибок рекурсии при отладке, при вызове функции
\cdf{*debugger-hook*} связывается со значением \cdf{nil}. Когда вычисляемый код
вводится пользователем интерактивно, функция-ловушка может захотеть связать
\cdf{*debugger-hook*} с функцией, которая была во втором аргументе, так что
ошибки рекурсии могут быть обработаны с помощью того же интерактивного функционала.
\end{defun}

\section{Определённые типы условий}        
\label{PREDEFINED-CONDITIONS-SECTION}

Все типы условий являются класса CLOS и все объекты условий являются простыми
CLOS объектами.

\begin{defun}[Тип]
restart 

Тип данных для представления перезапуска.
\end{defun}

\begin{table}[t]
\caption{Иерархия типов условий}
\label{CONDITION-HIERARCHY-TABLE}
\begin{lisp}
condition \\
~~~~simple-condition \\
~~~~serious-condition \\
~~~~~~~~error \\
~~~~~~~~~~~~simple-error \\
~~~~~~~~~~~~arithmetic-error \\
~~~~~~~~~~~~~~~~division-by-zero \\
~~~~~~~~~~~~~~~~floating-point-overflow \\
~~~~~~~~~~~~~~~~floating-point-underflow \\
~~~~~~~~~~~~~~~~... \\
~~~~~~~~~~~~cell-error \\
~~~~~~~~~~~~~~~~unbound-variable \\
~~~~~~~~~~~~~~~~undefined-function \\
~~~~~~~~~~~~~~~~... \\
~~~~~~~~~~~~control-error \\
~~~~~~~~~~~~file-error \\
~~~~~~~~~~~~package-error \\
~~~~~~~~~~~~program-error \\
~~~~~~~~~~~~stream-error \\
~~~~~~~~~~~~~~~~end-of-file \\
~~~~~~~~~~~~~~~~... \\
~~~~~~~~~~~~type-error \\
~~~~~~~~~~~~~~~~simple-type-error \\
~~~~~~~~~~~~~~~~... \\
~~~~~~~~~~~~... \\
~~~~~~~~storage-condition \\
~~~~~~~~... \\
~~~~warning \\
~~~~~~~~simple-warning \\
~~~~~~~~... \\
~~~~...
\end{lisp}
\vfill
\end{table}

Иерархия типов Common Lisp'овых условий представлена в
таблице~\ref{CONDITION-HIERARCHY-TABLE}.

Типы, которые не являются листьями в представленной иерархии (то есть
\cdf{condition}, \cdf{warning}, \cdf{storage-condition}, \cdf{error},
\cdf{arithmetic-error}, \cdf{control-error}, и так далее), представлены
преимущественно как контейнеры для других типов. Обычно объекты этих типов не
создаются.

Реализации могут как поддерживать непереносимые синонимы для этих типов, так и
вводить новые типы выше, ниже или между типами из указанного дерева, но не
нарушая иерархию.

Типы \cdf{simple-condition}, \cdf{serious-condition} и \cdf{warning} попарно не
пересекаются. Тип \cdf{error} также попарно не пересекается с типами
\cdf{simple-condition} и \cdf{warning}.

\begin{defun}[Тип]
condition

Все типы условий, и ошибок и не ошибок, должны наследоваться от этого типа.
\end{defun}

\begin{defun}[Тип]
warning

Все типы предупреждений, должны наследоваться от этого типа. Данный тип является
подтипом \cdf{condition}.
\end{defun}

\begin{defun}[Тип]
serious-condition

Все важные условия (условия достаточно серьёзны, чтобы требовать интерактивного
вмешательства, если они не были обработаны) должны наследоваться от этого типа. 

Этот тип условий представлен прежде всего для терминологического
удобства. Фактически, сигнализирование условия, которое унаследовано от
\cdf{serious-condition} не заставляет отладчик вмешиваться. Скорее удобно
использовать \cdf{error} (или обёртку над ней) для сигнализирования условий
этого типа, и использовать \cdf{signal} для сигнализирования условий других типов.
\end{defun}

\begin{defun}[Тип]
error

Все типы ошибок, должны наследоваться от этого типа. Данный тип является
подтипом \cdf{serious-condition}.
\end{defun}

Тип условия по-умолчанию для \cdf{signal} и \cdf{warn} ---
\cdf{simple-condition}.
Тип условия по-умолчанию для \cdf{error} и \cdf{cerror} --- \cdf{simple-error}.

\begin{defun}[Тип]
simple-condition

Данный тип используется в функции \cdf{signal}, когда в неё в качестве первого
аргумента передаётся строка форматирования. Данный тип является подтипом
\cdf{condition}. Для инициализации слотов поддерживаются 
параметры \cd{:format-string} и \cd{:format-arguments}. Эти слоты доступны с
помощью \cdf{simple-condition-format-control} и
\cdf{simple-condition-format-arguments}. Если в \cdf{make-condition}
\cd{:format-arguments} не указан, то слот \emph{format-arguments} по-умолчанию
будет равен \cdf{nil}.
\end{defun}

\begin{defun}[Тип]
simple-warning

Данный тип используется в функции \cdf{warn}, когда в неё в качестве первого
аргумента передаётся строка форматирования. Данный тип является подтипом
\cdf{condition}. Для инициализации слотов поддерживаются 
параметры \cd{:format-string} и \cd{:format-arguments}. Эти слоты доступны с
помощью \cdf{simple-condition-format-control} и
\cdf{simple-condition-format-arguments}. Если в \cdf{make-condition}
\cd{:format-arguments} не указан, то слот \emph{format-arguments} по-умолчанию
будет равен \cdf{nil}.

В реализациях поддерживающих множественное наследование, данный тип будет также
подтипом \cdf{simple-condition}.
\end{defun}

\begin{defun}[Тип]
simple-error

Данный тип используется в функциях \cdf{error} и \cdf{cerror}, когда в них в
качестве первого аргумента передаётся строка форматирования. Данный тип является
подтипом \cdf{condition}. Для инициализации слотов поддерживаются параметры
\cd{:format-string} и \cd{:format-arguments}. Эти слоты доступны с помощью
\cdf{simple-condition-format-control} и
\cdf{simple-condition-format-arguments}. Если в \cdf{make-condition}
\cd{:format-arguments} не указан, то слот \emph{format-arguments} по-умолчанию
будет равен \cdf{nil}.

В реализациях поддерживающих множественное наследование, данный тип будет также
подтипом \cdf{simple-condition}.
\end{defun}

\begin{defun}[Функция]
simple-condition-format-control condition

Предоставляет доступ к значению слота \cd{format-string} для объекта условия
\emph{condition}, который должен принадлежать одному из типов
\cdf{simple-condition}, \cdf{simple-warning}, \cdf{simple-error} или
\cdf{simple-type-error}
\end{defun}

\begin{defun}[Функция]
simple-condition-format-arguments condition

Предоставляет доступ к значению слота \cd{format-arguments} для объекта условия
\emph{condition}, который должен принадлежать одному из типов
\cdf{simple-condition}, \cdf{simple-warning}, \cdf{simple-error} или
\cdf{simple-type-error}
\end{defun}

\begin{defun}[Тип]
storage-condition

Условие, которое связано с переполнением некоторого хранилища, должно
наследоваться от этого типа. Данный тип является подтипом для \cdf{serious-condition}.
\end{defun}

\begin{defun}[Тип]
type-error

Ошибки в программе при передаче данных должны наследоваться от данного
типа. Данный тип является подтипом \cdf{error}. Например, условия, которые
генерируются с помощью \cdf{check-type}, должны наследоваться  от данного
типа. Для инициализации соответствующих слотов используются инициализационные
аргументы \cd{:datum} и \cd{:expected-type}. Содержимое слотов доступно с
помощью \cdf{type-error-datum} и
\cdf{type-error-expected-type}.
\end{defun}

\begin{defun}[Функция]
type-error-datum condition

Предоставляет доступ к значению слота \cd{datum} объекта условия
\emph{condition}, который должен принадлежать типу \cdf{type-error}.
\end{defun}

\begin{defun}[Функция]
type-error-expected-type condition

Предоставляет доступ к значению слота \cd{expected-type} объекта условия
\emph{condition}, который должен принадлежать типу
\cdf{type-error}. Предполагается, что пользователи \cdf{type-error} установят
в данный слот объект, которые являются корректным Common Lisp'овым
спецификатором типа.
\end{defun}

\begin{defun}[Тип]
simple-type-error

Условия, которые сигнализируются функциями, вроде \cdf{check-type}, могут
использовать данный тип. Для инициализации одноимённых слотов используются
параметры \cd{:format-string} и \cd{:format-arguments}. Для доступа к этим
слотам используются соответственно \cd{simple-condition-format-control} и
\cdf{simple-condition-format-arguments}. Если в \cdf{make-condition}
\cd{:format-arguments} не был указан, одноимённый слот будет равен \cdf{nil}.
\end{defun}

\begin{defun}[Тип]
program-error

Ошибки, связанные с некорректным синтаксисом программы, и которые могут быть
определены статически, должны наследоваться от этого типа (вне зависимости от
того, статически ли они были определены). Этот тип является подтипом
\cdf{error}. Данный тип не наследует тип \cdf{control-error}.
\end{defun}

\begin{defun}[Тип]
control-error

Ошибки в динамической передаче управления в программе должны наследоваться от
данного типа. Этот тип является подтипом \cdf{error}. Данный тип не наследуется
от \cdf{program-error}.

Эти ошибки получаются, если тег для \cdf{throw} больше не является активным или
тег для \cdf{go} или \cdf{return-from} больше не доступен в динамическом
контексте.

В другой стороны, ошибки в связи с недоступными в лексическом окружении тегами
для \cdf{go} или \cdf{return-from} являются программными ошибками (program
errors). Смотрите \cdf{program-error}.
\end{defun}


\begin{defun}[Тип]
package-error

Ошибки, которые возникают в операциях над пакетами, должны наследоваться от
данного типа. Этот тип является подтипом \cdf{error}. Для инициализации
одноимённого слота используется параметр \cd{:package}. Доступ к данному слоту
осуществляется с помощью \cdf{package-error-package}.
\end{defun}

\begin{defun}[Функция]
package-error-package condition

Предоставляет доступ к пакету (или имени пакета), который фигурирует в условии
\emph{condition} типа \cdf{package-error}
\end{defun}

\begin{defun}[Тип]
stream-error

Ошибки, которые случаются в процессе ввода из, вывода в, закрытия потока, должны
наследоваться от данного типа. Этот тип является подтипом \cdf{error}. Для
инициализации одноимённого слота используется параметр \cd{:stream}. Доступ к
слоту осуществляется с помощью \cdf{stream-error-stream}.
\end{defun}

\begin{defun}[Функция]
stream-error-stream condition

Даёт доступ к потоку, который фигурировал в условии \emph{condition} типа
\cdf{stream-error}.
\end{defun}

\begin{defun}[Тип]
end-of-file

Ошибка данного типа возникает при операции чтения из потока, в котором больше не
осталось элементов. Данный тип является подтипом \cdf{stream-error}.
\end{defun}

\begin{defun}[Тип]
file-error

Ошибки, которые случаются при попытке открыть файл, или в процессе
низкоуровневых операций с файловой системой, должны наследоваться от этого
типа. Этот тип является подтипом \cdf{error}. Для инициализации одноимённого
слота используется параметр \cd{:pathname}. Доступ к слоту осуществляется с
помощью \cdf{file-error-pathname}.
\end{defun}

\begin{defun}[Функция]
file-error-pathname condition

Предоставляет доступ к имени файла --- слота в условии \emph{condition} типа
\cdf{file-error}.
\end{defun}

\begin{defun}[Тип]
cell-error

Ошибки, которые возникают при доступе к некоторым сущностям, должны
наследоваться от этого типа. Данный тип является подтипом \cdf{error}. Для
инициализации соответствующего слота поддерживается инициализационный аргумент
\cd{:name}. Значение данного слота может быть получено с помощью \cdf{cell-error-name}.
\end{defun}

\begin{defun}[Функция]
cell-error-name condition

Предоставляет доступ к значению слота \cd{error-name} для условия
\emph{condition} типа \cdf{cell-error}.
\end{defun}

\begin{defun}[Тип]
unbound-variable

Ошибка, возникает при попытке доступа к несвязанной переменной. Данный тип
наследует \cdf{cell-error}.
\end{defun}

\begin{defun}[Тип]
undefined-function

Ошибка, возникает при попытке доступа к неопределённой функции. Данный
тип наследует \cdf{cell-error}.
\end{defun}

\beforenoterule
\begin{sideremark} [Note: This remark was written well before the vote by X3J13
in June 1988 \issue{CLOS} to add the Common Lisp Object System to the
forthcoming draft standard (see chapter~\ref{CLOS}) and the vote to integrate
the Condition System and the Object System.  I have retained the remark here for
reasons of historical interest.---GLS]

Some readers may wonder why \cdf{undefined-function} is not defined to inherit
from some condition such as \cdf{control-error}. The answer is that any such
arrangement would require the presence of multiple inheritance---a  luxury we do
not currently have (without resorting to \cdf{deftype}, which  we are currently
avoiding). When the Common Lisp Object System comes into being, we might want to
consider issues like this.  Multiple inheritance makes a lot of things in a
condition system much more flexible to deal with.
\end{sideremark}
\afternoterule

\begin{defun}[Тип]
arithmetic-error

Данный тип условия используется при возникновении ошибок во время выполнения
арифметических операций. Данный тип является подтипом \cdf{error}. Для
соответствующих слотов могут указываться инициализационные аргументы
\cd{:operation} и \cd{:operands}. Получение данных значений выполняется
функциями \cdf{arithmetic-error-operation} и \cdf{arithmetic-error-operands}.
\end{defun}

\begin{defun}[Функция]
arithmetic-error-operation condition

Предоставляет доступ к операции в объекте условия типа \cdf{arithmetic-error}.
\end{defun}

\begin{defun}[Функция]
arithmetic-error-operands condition

Предоставляет доступ к операндам в объекте условия типа \cdf{arithmetic-error}.
\end{defun}

\begin{defun}[Тип]
division-by-zero

Ошибки, которые возникают из-за деления на ноль, должны наследовать от этого
типа. Данный тип является подтипом \cdf{arithmetic-error}.
\end{defun}

\begin{defun}[Тип]
floating-point-overflow

Ошибки, которые возникают из-за переполнения (overflow) в вычислениях с
плавающей точкой, должны наследовать от этого типа. Данный тип является подтипом
\cdf{arithmetic-error}.
\end{defun}

\begin{defun}[Тип]
floating-point-underflow

Ошибки, которые возникают из-за переполнения (underflow) в вычислениях с
плавающей точкой, должны наследовать от этого типа. Данный тип является подтипом
\cdf{arithmetic-error}.
\end{defun}
\fi