Error processing for GFP makes use of COMMON LISP condition signals. We introduce the new condition types shown in Figure 5.1. The general rule is that errors of these types will be signaled by GFP when these exceptions occur. If, for example, the user attempts to retrieve slot values from a frame that does not exist, using a call to the function get-slot-values , the error frame-not-found is signaled. Or, if the user asserts a value into a slot that violates a constraint associated with that slot, the appropriate constraint violation condition is signaled.
Error conditions can also be signalled when slot constraints are detected. When a constraint violation occurs, the FRS should signal one of the conditions defined in Figure 5.1. For example, calling put-slot-values , can violate a slot cardinality or value type constraint. In the Generic Frame Protocol, when a constraint violation condition is signaled, the slot will have been modified to contain the offending value. The rationale for leaving the offending values in the slot is to allow some applications to ignore the violations.
Figure 5.1: Error conditions of the Generic Frame Protocol.
One exception to that rule is those functions that take an argument called error-p. The argument controls whether error signaling occurs for specifically defined errors. Errors are signaled when its value is t (the default); the value nil inhibits error signaling for the type of error that error-p controls for each function.
A second exception is the functions whose names begin with delete, remove, add and replace. These functions do not signal errors if the thing to be removed or replaced does not exist, or if the thing to be added already exists. This approach simplifies the implementation and speeds performance since each underlying FRS may make different assumptions about signaling behavior. If the user requires more strict checking, their application should implement this checking using the predicates that GFP provides.