Next: Sections Not Formally Part Of This Standard, Previous: Notational Conventions, Up: Definitions
Situations in which errors might, should, or must be signaled are described in the standard. The wording used to describe such situations is intended to have precise meaning. The following list is a glossary of those meanings.
safety
optimization
at its highest setting (3
). safety
is a lexical property
of code. The phrase “the function F
should signal an error”
means that if F
is invoked from code processed with the highest
safety
optimization, an error is signaled.
It is implementation-dependent whether F
or the calling
code signals the error.
Unsafe code might do error checking. Implementations are permitted to
treat all code as safe code all the time.
unexport
is given a symbol
not accessible in the current package.”
If an explicit error type is not specified, the default is error
.
+
should signal an error of type type-error
if any argument is not of type number
.”
For example, defining that
“find
should be prepared to signal an error of type type-error
if its second argument is not a proper list”
does not imply that an error is always signaled. The form
(find 'a '(a b . c))
must either signal an error of type type-error
in safe code,
else return A
.
In unsafe code, the consequences are undefined.
By contrast,
(find 'd '(a b . c))
must signal an error of type type-error
in safe code.
In unsafe code, the consequences are undefined.
Also,
(find 'd '#1=(a b . #1#))
in safe code
might return nil
(as an implementation-defined extension),
might never return,
or might signal an error of type type-error
.
In unsafe code, the consequences are undefined.
Typically, the “should be prepared to signal” terminology is used in
type checking situations where there are efficiency considerations that
make it impractical to detect errors that are not relevant to the
correct operation of the operator.
shared-initialize
specifies a name that does not correspond to any slots
accessible in the object, the results are unspecified.”
For example: “Once a name has been declared by defconstant
to be constant, any further assignment or binding of that
variable has undefined consequences.”
open
might signal an error of type file-error
.”
A program can be well-specified even if it uses a function whose
returns values are unspecified. For example, even if the return
values of some function F
are unspecified, an expression such as
(length (list (F)))
is still well-specified because it does not
rely on any particular aspect of the value or values returned by F
.
No conforming code may depend on the consequences of such a situation; all conforming code must treat the consequences of the situation as undefined. Implementations are required to document how the situation is treated.
For example, “implementations may be extended to define other type
specifiers to have a corresponding class.”
defclass
.”