XLISP-STAT now uses an implementation of the Common Lisp condition system for error handling. The functions error , cerror , warn , and signal signal errors, continuable errors, warnings, or general conditions, respectively.
The macro ignore-errors takes an expression argument and returns either the values of that expression in the current environment if there is no error, or the values nil and the error condition signaled:
> (ignore-errors (values 1 2)) 1 2 > (ignore-errors (error ``an error'')) NIL #<Condition SIMPLE-ERROR: 13023072>
The macros assert and check-type for type and predicate checking and the macros ccase , ctypecase signal continuable errors. The macros check-type , ccase , ctypecase , ecase , and etypecase signal errors of type type-error .
At this point the implementations of these macros are bare bones and may not actually provide continuable errors or the right error type but that should be changed soon.
Conditions handlers are set up and used with the functions and macros
Restarts can be manipulated using the following functions and macros:
The function invoke-debugger provides a low level interface to the debugger.
All standard predefined condition types are implemented, including the accessor functions
Conditions are currently implemented as structures and therefore do not support multiple inheritance.
For the most part internal errors still signal errors of type simple-error . This will be changed eventually. One exception is unbound variable and unbound function errors -- these are already of types unbound-variable and unbound-function , respectively. This may eventually be used to define a more sophisticated autoload facility.
Currently stack overflow errors are not signalled at the system state where they occur, because trying to handle them without any stack space would lead to an infinite error recursion. Instead they are signaled from the most recent handler-bind , in such a way as to insure that a stack overflow in a handler is caught in the next most recent one.In the future, I will try to generate low stack errors that allow a limited amount of exploring the system state before a real overflow occurs. I think this can be done fairly easily without a performance penalty, but I'm not sure yet.