| Allegro CL version 8.2 Unrevised from 8.1 to 8.2. 8.1 version |
This document contains the following sections:
1.0 ErrorsErrors in Allegro CL are handled by the condition system as described in the ANSI spec. Note too that some errors in Allegro CL are still classified as simple-errors when they should be classified otherwise.
The errorset macro is preserved from earlier versions of Allegro CL although its functionality is completely superceded by the condition system. It is maintained for backward compatibility and its use in newly written code is not recommended.
Here is the condition type hierarchy. Allegro CL has some additional error types defined. They are marked with an *. The ones with links are further described. You can get the condition object associated with an error with the top-level command :error, which, besides printing the error message sets the value of * to the condition object.
condition
advance-warning * input-edit * ics-dependent-classa * ics-dependent-classb * compiler-note *serious-condition
storage-condition
error
type-error
case-failure
*simple-type-error
stream-errorstream-closed-error
*end-of-file
reader-error
(also subclass of parse-error)socket-error
*errno-stream-error
*parse-error
reader-error
(also subclass of stream-error)operating-system-signal
*synchronous-operating-system-signal
*asynchronous-operating-system-signal
*interrupt-signal
*package-error
package-locked-error
*file-error
file-does-not-exist-error
*autoload-file-does-not-exist-error
*cell-error
unbound-slot
undefined-function
unbound-variable
print-not-readable
arithmetic-error
floating-point-inexact
floating-point-invalid-operation
floating-point-underflow
[see note after table]floating-point-overflow
division-by-zero
compiler-not-available-error
*program-error
control-error
simple-error
socket-error
*syscall-error
*winapi-error
*simple-break
break-condition
*warning
compiler-not-available-warning
*incompatible-conformance-change-warning
*simple-warning
style-warning
ineffective-declaration-warning
*compiler-undefined-functions-called-warning
*compiler-no-in-package-warning
*compiler-unreachable-code-warning
*compiler-inconsistent-name-usage-warning
*simple-condition
simple-type-error
simple-error
simple-break
*simple-warning
floating-point-underflow
is not usually signaled
because most operating systems silently replace an underflow with zero
without further action.
The stream-error
class, as implemented in Allegro CL, has these slots:
stream
: the stream which got the error. This is
the standard CL slot and is accessed by stream-error-stream.
action
: the action that was being attempted at
the time of the error, accessed by stream-error-action.
code
: the errno code returned from the system,
nil if none. Accessed by stream-error-code.
identifier
: symbolic identification of the
code, or nil if unknown. Accessed by stream-error-identifier.
With the new stream-error conditions and slots, Allegro CL classifies
stream error situations when possible, relying on a catch-all
condition to hold errno returns that could not be classified. A user
might want to do handler-binds
on the condition subclasses, or on the stream-error condition and then
test the identifier slot. All stream conditions have such an
identifier slot, but some conditions (especially the catch-all errno-stream-error
condition) may not fill it in.
In particular, when a system operation returns an errno value, it is
looked up to see if it is a socket-error, and if so, a socket-error
condition is
created. It is intended then that other errno classifications will be
tried. If no classification can be made, then an errno-stream-error
condition is
created. Its identifier slot is set to :unknown
,
but an attempt is made to find out from the operating system what the
string for such an error is, and that is stored into the condition in
the string slot, for easier human identification.
We list here some common error messages. This list is by no means exhaustive and we only give a brief description of the likely cause. Error messages start with Error:, but we leave that out here. Names (of functions, symbols, etc.) that appear in error messages are replaced with [name] or some other generic placeholder.
This is printed when an error occurs while Lisp was running through its startup procedure. [message] is the error message generated by the actual error. The startup fails as a result of the error. Assuming the startup procedure has not been changed, these cannot be the cause of this error:
*restart-init-function*
or *restart-app-function*
.
These functions are called outside the handler which prints the An unhandled error ...
message.These may be the cause:
-e [form]
command-line argument. Try to start
without the -e
arguments.*restart-actions*
.
Try to start with the following on the command line (it suppresses any restart actions).
Be sure to wrap the parentheses with ' marks or other shell-specific quotation-like marks.
-e (setq excl:*restart-actions* nil)
Code calling [name] was compiled before [name] was defined as a macro is the cause.
user(1): (defun foo () (bar) 10) foo user(2): (compile *) Warning: While compiling these undefined functions were referenced: bar. foo nil nil user(3): (defmacro bar nil nil) bar user(4): (foo) Error: Attempt to call bar which is defined as a macro. [condition type: undefined-function] [1] user(5):
The example above shows the definitions typed to the top-level, but this error is most commonly caused when files are compiled in the wrong order.
See gc errors in gc.htm where these errors are discussed.
Bus errors and segmentation violations are standard OS errors. They
are not specific to Lisp. Typically, a bus error is caused by an
attempt to write to read-only memory while a segmentation violation is
an attempt to access memory that does not exist. You may see them
signaled in Lisp, usually when an error is signaled from code compiled
at high speed and low safety (so standard Lisp error checkers are not
used). If you see such an error, try recompiling code at higher safety
and lower speed (in particular, make trust-declarations-switch
return nil
) and see whether the error
persists.
Suppose you try to call a function in a currently-unused package but
forget the package qualifier. For example, suppose you called process-run-function
without the mp:
and the multiprocessing package is not
used. You get an error about process-run-function not
having a function definition (as expected). Then you use the
multiprocessing package by evaluating (use-package
:mp)
. The following error will be signaled:
Error: Using package `MULTIPROCESSING' results in name conflicts for these symbols: PROCESS-RUN-FUNCTION [condition type: PACKAGE-ERROR] Restart actions (select using :continue): 0: Unintern the conflicting symbols from the `COMMON-LISP-USER' package. [...]
In order for process-run-function
typed without
a package qualifier to be mp:process-run-function, enter
:continue 0
See the top-level command :continue.
Note that in earlier (than 6.1) releases of Allegro CL, the error message was:
Error: Using package `MULTIPROCESSING' results in name conflicts for these symbols: PROCESS-RUN-FUNCTION [condition type: PACKAGE-ERROR] Restart actions (select using :continue): 0: Unintern the conflicting symbols in the `MULTIPROCESSING' package. [...]
Most users found that description of what happens when
:continue 0
is entered confusing, and were unable
to tell from the message what action would produce the desired
result. The action is still :continue 0
. It is
hoped the revised message makes that more clear.
Many Common Lisp sequence function are sensitive to the type of their arguments. Consider the following incorrect forms:
(make-list nil) ;; argument should be an integer. NIL is illegal (elt #(1 2 3) nil) ;; second argument should be an integer. ;; NIL is illegal (mapcar #'alpha-char-p "N ") ;; second argument should be a list ;; not a string
In each case, the argument given is wrong, but not unreasonable, and a programmer could carelessly but understandably make the errors shown (indeed, all these errors come from our support files). But note they reached our support files because the result (in earlier releases of Allegro CL) of evaluating the erroneous form was more serious than expected: rather than simply signaling an error, Lisp would in some cases enter an infinite loop and have to be interrupted.
In safe code, sequence functions such as the ones above should check that their arguments are of the correct type and signal a type error if they are not. But there is always a price to pay for argument checking: it consumes machine cycles in every call to a function in order to weed out erroneous code.
Allegro CL has two sequence function modules:
:safeseq
and :fastseq
. Either
two can be require'd at any time, and they
each cancel the effect of the other. These modules hold the safe or
fast run-time definitions of several problematic sequence functions
that are hard to decide how to balance between safety and speed.
Thus, to use safe sequence functions, evaluate at any time:
(require :safeseq)
And to use fast (but without argument checking) sequence functions, evaluate at any time:
(require :fastseq)
It should be noted that functions in the :safeseq
module are not better per se than those in
:fastseq
, and for correct code each module's
functions operate correctly. Rather, the functions in
:safeseq
behave better with improper arguments.
The current list of functions which are affected by these modules include (but are not limited to, possibly by indirection): elt, length, make-list, mapc, mapcar, mapcon, mapl, butlast, and nbutlast.
In development images, the module loaded by default in
:safeseq
. In production images (when the
runtime argument to generate-application is non-nil
), the default is :fastseq
.
Copyright (c) 1998-2016, Franz Inc. Oakland, CA., USA. All rights reserved.
This page was not revised from the 8.1 page.
Created 2010.1.21.
| Allegro CL version 8.2 Unrevised from 8.1 to 8.2. 8.1 version |