cl-condition-system

The condition system separates error notification from recovery by defining custom conditions, providing restart options with restart-case, and binding handlers with handler-bind or handler-case. This enables robust, reusable error handling across input validation, file IO, configuration parsing, and retry logic.

handler-bind executes handler code in the dynamic context where the condition occurred, allowing inspection and restart selection; handler-case catches conditions and executes clauses in the caller's context. Use handler-bind for logging and recovery delegation, handler-case for immediate branching on specific condition types.

Use define-condition to create custom error and warning types organized in hierarchies. Structure conditions with slots for error details and parent types to establish inheritance, enabling precise condition matching and targeted handler binding across your application.

Yes. Wrap code in restart-case to define restart options like retry or skip, then use handler-bind to invoke those restarts on specific conditions. This pattern decouples error detection from recovery strategy, making retry flows composable and reusable across validation, IO, and transactional operations.

Use the condition system when you need non-local recovery, interactive restart selection, or separation of error signaling from handling policy. It excels in scenarios requiring multiple recovery paths, unwind-protect coordination, and reporting—tasks where traditional exceptions force handler placement at the call site.

Restarts invoked by handlers respect unwind-protect cleanup forms, ensuring resources are released before transfer of control. This allows handlers and restarts to coexist safely with resource-cleanup code, enabling robust patterns for file operations and transactional cleanup.