Like reikonomusha said, CL's condition system is pretty general in itself. The naming choice isn't an accident - the thing that's being "raised" is a "condition" (of which "error" is just a subtype), and what you do with a condition is "signal" it. In CL, most of the time it's used for exception handling, but I've seen code using this system for tasks not related to errors.
As a simple example, you can imagine data processing function for use in potentially interactive application, that reports progress and allows for aborting:
(define-condition progress ()
((amount :initarg :amount :reader amount)))
(defun process-partial-data (data)
"NOOP placeholder"
(declare (ignore data)))
(defun process-data (data)
(restart-case
(loop
initially
(signal 'progress :amount 0)
with total = (length data)
for datum in data
for i below total
do
(process-partial-data datum)
(signal 'progress :amount (/ i total))
;; Report progress
finally
(signal 'progress :amount 1)
(return :done))
(abort-work ()
(format *trace-output* "Aborting work!")
:failed)))
The "business meat" of our function is the loop form. You'll notice it reports its progress by signalling a 'progress condition, which, without installed handlers, is essentially a no-op (unlike throwing an exception). The "meat" is wrapped in restart-case form, in order to provide an alternative flow called 'abort-work (you can provide more than one named flow).
Now for the REPL sessions (-> denotes returned value). First, regular use:
CL-USER> (process-data '(1 2 3 4 5 6))
-> :DONE
Let's simulate a GUI progress bar, by actually listening to the 'progress condition:
A progress bar in a GUI usually has a "cancel" button. Let's simulate it by assuming that user clicked "cancel" around the 50% progress mark, through invoking the 'abort-work restart programmatically:
You'll note that function code is entirely transparent for how the progress reporting and abort decision work; it's callee-level handlers that are concerned with it. It works in console, it can work with Lisp's interactive debugger, and it could work with a GUI just as well. Hell, it could work with network requests (and I've seen similar code for writing handler response code for multiple protocols, letting you deliver partial results where supported, and transparently buffering them where it isn't.)
N.b. your typical experience with restarts in Common Lisp is the interactive debugger that pops up when an error gets unhandled. This example serves as a reminder that restarts are not just for errors, and that you can invoke them programmatically - building applications that can figure out how to handle their own errors.
And this then would expand into a machinery like above.
The Lisp Machine OS had a system-wide progress bar at the bottom of the screen, which then would show the progress of some process - usually the front process or something related.
As a simple example, you can imagine data processing function for use in potentially interactive application, that reports progress and allows for aborting:
The "business meat" of our function is the loop form. You'll notice it reports its progress by signalling a 'progress condition, which, without installed handlers, is essentially a no-op (unlike throwing an exception). The "meat" is wrapped in restart-case form, in order to provide an alternative flow called 'abort-work (you can provide more than one named flow).Now for the REPL sessions (-> denotes returned value). First, regular use:
Let's simulate a GUI progress bar, by actually listening to the 'progress condition: A progress bar in a GUI usually has a "cancel" button. Let's simulate it by assuming that user clicked "cancel" around the 50% progress mark, through invoking the 'abort-work restart programmatically: You'll note that function code is entirely transparent for how the progress reporting and abort decision work; it's callee-level handlers that are concerned with it. It works in console, it can work with Lisp's interactive debugger, and it could work with a GUI just as well. Hell, it could work with network requests (and I've seen similar code for writing handler response code for multiple protocols, letting you deliver partial results where supported, and transparently buffering them where it isn't.)N.b. your typical experience with restarts in Common Lisp is the interactive debugger that pops up when an error gets unhandled. This example serves as a reminder that restarts are not just for errors, and that you can invoke them programmatically - building applications that can figure out how to handle their own errors.