condition!!! Barrett notes of the condition types: There is little discussion in this descriptions of what the values of the initargs ought to be. For example, package-error permits name or package object.
condition, t
All types of conditions, whether error or non-error, must inherit from this type. As noted by Symbolics, these just repeat the obvious: All types of \term{conditions} are \term{classes}. All \term{condition} \term{objects} are \term{generalized instances} of one or more \term{classes}. Barmar thinks the next statement is unnecessary and incomplete. I think there's also a later cleanup issue which undoes it. Work on this more. -kmp Barrett also asks what about SLOT-VALUE and its setf. Removed. This is explained better below. -kmp 1-Oct-91 \term{Slots} in \term{condition} \term{objects} can be accessed using \macref{with-slots}.
!!! Barrett points out that these look a little lonely all by themselves. -kmp 23-Oct-90 (Well, they used to be somewhere different, so maybe they are not so lonely now, but I'll leave the comment and think more about it later. -kmp 13-Nov-90) !!! Barrett thinks this "disjointness" is probably false and in any case uninteresting. Finally commented out for Barrett. -kmp 2-Feb-92 The \term{types} \typeref{simple-condition}, \typeref{warning}, and \typeref{serious-condition} are \term{pairwise} \term{disjoint}.
No additional subtype relationships among the specified subtypes of type condition are allowed, except when explicitly mentioned in the text; however implementations are permitted to introduce additional types and one of these types can be a subtype of any number of the subtypes of type condition.
Whether a user-defined condition type has slots that are accessible by with-slots is implementation-dependent. Furthermore, even in an implementation in which user-defined condition types would have slots, it is implementation-dependent whether any condition types defined in this document have such slots or, if they do, what their names might be; only the reader functions documented by this specification may be relied upon by portable code.
Conforming code must observe the following restrictions related to conditions:
define-condition, not defclass, must be used to define new condition types.
make-condition, not make-instance, must be used to create condition objects explicitly.
:report option of define-condition, not defmethod for print-object, must be used to define a condition reporter.
slot-value, slot-boundp, slot-makunbound, and with-slots must not be used on condition objects. Instead, the appropriate accessor functions (defined by define-condition) should be used.