“Lisp 的状况系统（condition system）是它最伟大的特性之一。”
有没有最伟大我还不是很清楚，但可以肯定的是给了我耳目一新的感觉。
会 Java 的应该都对了解其异常处理的机制，这一类型的异常处理方式估计是使用最广泛（Python, JavaScript, etc）的了。
其表达形式也比较简单：（以 Java 为例）
try {
// do something could cause exception
} catch (Exception e) {
// handle exception
}
而且，产生的异常如果不好处理还可以往上抛（throw exception），当异常向上层抛出的时候，异常信息以异常对象的形式向上传递，调用栈会展开（unwind），如果某一层没 catch 住或者处理不了继续往上抛。相当不错的模型，简洁易用。
似乎一切异常都逃不出手掌心了。到现实中的代码翻翻看。先排除掉哪些 catch 块里面没有任何东西，或者不写 try catch 直接声明 throw 的情况，因为不使用就没有发言权。可以观察到下面的情况出现得相当的多。
e.printStackTrace(); throw e;
顿时有种泪流满面的感觉，教科书上的内容还记得 T_T
好吧，那证明不了什么，只是说明了水平不够，没能领悟异常处理的真谛。
假设我们已经在 catch 里花了许多心思处理异常，异常只有一种处理方式的时候还好，一旦有多种处理方式，在什么情况下选择怎么处理就变得棘手起来，由于我们尽量期望一个方法只做它自己事情，选择哪个处理方式又是很可能与上层调用环境有关，要么是在调用时一并传入更多上下文信息，要么是抛出异常，由外层去选择和处理，只是怎么处理异常情况应该是下层的方法了解得最清楚，一旦异常抛出，栈已经被展开，前缘难续。当然，模型本身是没有什么对错的，只是看怎么用，用起来是否费劲。
从概念上比较，Lisp 的状况系统理解起来是有点费劲的，但用法却比较简单。貌似它的一些其它特性也是这样子。
状况系统将整个过程分成：产生（signaling）状况，处理（handling）它以及再启动（restarting）。与突出异常的情况不同，Lisp 更倾向于处理并从错误状况中恢复。但是，底层函数中是可以不决定选择哪种恢复策略，将决定权留给高层函数的代码。我们要做的事情就是思考会出现什么状况，出现状况的时候有什么策略来应对，以使程序可以继续运行下去。这要求比简单捕捉或抛出异常要更进了一步。
下面 Lisp 代码引用自 《实用 Common Lisp 编程》。
(define-condition malformed-log-entry-error (error)
((text :initarg :text :reader text)))
(defun skip-log-entry (c)
(invoke-restart 'skip-log-entry))
;; set up the conditions
(defun parse-log-entry (text)
(if (well-formed-log-entry-p text)
(make-instance 'log-entry …)
(restart-case (error 'malformed-log-entry-error :text text)
(use-value (value) value)
(reparse-entry (fixed-text) (parse-log-entry fixed-text)))))
;; 'skip-log-entry' will be shown in the debugger when error occur
(defun parse-log-file (file)
(with-open-file (in file :direction :input)
(loop for text = (read-line in nil nil) while text
for entry = (restart-case (parse-log-entry text)
(skip-log-entry () nil))
when entry collect it)))
(defun analyze-log (log)
(dolist (entry (parse-log-file log))
(analyze-entry entry)))
;; handle the condition
(defun log-analyzer ()
(handler-bind ((malformed-log-entry-error
#'(lambda (c)
(use-value
(make-instance 'malformed-log-entry :text (text c))))))
(dolist (log (find-all-logs))
(analyze-log log))))
调用是从 log-analyzer > analyze-log > parse-log-file > parse-log-entry 逐层深入。在 parse-log-entry 产生状况（malformed-log-entry-error）。然后可以使用 HANDLER-CASE 宏来定义状况处理器（handler），以响应状况的信号处理，但如果只是这样的话，就和普通异常处理没什么区别。
状况系统允许我们将处理代码拆分成两部分：从错误中恢复用的再启动（restart），和状况处理器（handler）。前者可以位于较下层的函数，后者位于更上层。
Restart 提供了可选的处理策略，因为并不是所有的应用都会采取某种固定的处理方式。比如，例子中 parse-log-entry 提供了 use-value 和 reparse-entry 两种处理方式，可以直接提供一个值，或者修复数据后重新分析。多个处理策略有时是很有用甚至是必须的。应用需要运行在测试环境与生产环境等不同环境中时，就有许多需要不同的处理策略的情况。
log-analyzer 是顶层函数，函数内通过 HANDLER-BIND 宏绑定状况处理器。重点在于，当下层函数出现状况时，上层函数可以选择处理策略，而执行处理策略的还是在下层函数的调用栈内，因为整个过程里栈是不展开的，可以在原有上下文环境下继续进行处理。
某种意义上讲，状况系统与异常处理根本就不是一回事。
我感觉就是两种完全不同的处理方式。当你与一个朋友因为一些状况发生争执时，如果这事在两人之间能处理掉那是最好，处理不了或者无法决定处理办法，拼命地往上冲突，朋友关系可能就因此破裂了，就算后面再努力挽回，重新建立的已经不是以前的那份友情了。但如果只要有修复的可能，上层有比如珍惜彼此多年情谊这样的大前提，是能决出一种处理办法来修复，从而很好地延续了友情。
一切都在继续。
PS: 初学 Lisp，实践不多，如果理解得不正确，还望看官们多多提点。