;;; CLHS 9.1.4 Signaling and Handling Conditions
;;;
;;; http://www.lispworks.com/documentation/HyperSpec/Body/09_ad.htm
;;;
;;; > Once a handler in a handler binding form (such as HANDLER-BIND or
;;; > HANDLER-CASE) has been selected, all handlers in that form become inactive
;;; > for the remainder of the signaling process. While the selected handler
;;; > runs, no other handler established by that form is active. That is, if the
;;; > handler declines, no other handler established by that form will be
;;; > considered for possible invocation.

;;; CLHS HANDLER-BIND
;;;
;;; http://www.lispworks.com/documentation/HyperSpec/Body/m_handle.htm#handler-bind
;;;
;;; > If more than one handler binding is supplied, the handler bindings are
;;; > searched sequentially from top to bottom in search of a match (by visual
;;; > analogy with typecase). If an appropriate type is found, the associated
;;; > handler is run in a dynamic environment where none of these handler
;;; > bindings are visible (to avoid recursive errors). If the handler declines,
;;; > the search continues for another handler.
;;;
;;; > If no appropriate handler is found, other handlers are sought from
;;; > dynamically enclosing contours. If no handler is found outside, then
;;; > signal returns or error enters the debugger.

(defun printer (thing)
  (lambda (&rest args)
    (declare (ignore args))
    (print thing)))

(handler-bind ((simple-condition (printer "First"))
               (condition (printer "Second")))
  (signal "Test"))

;;; >> First
;;; >> Second
;;; => NIL

;;; TODO: Given all of the above, how is this behavior of HANDLER-BIND correct?
;;;
;;; CLHS 9.1.4 says:
;;;
;;; > That is, if the handler declines, no other handler established by that
;;; > form will be considered for possible invocation.
;;;
;;; But this is not what we see, as both handlers have been called.
;;;
;;; CLHS HANDLER-BIND says:
;;;
;;; > If more than one handler binding is supplied, the handler bindings are
;;; > searched sequentially from top to bottom in search of a match (by visual
;;; > analogy with typecase). ... If the handler declines, the search continues
;;; > for another handler. If no appropriate handler is found, other handlers
;;; > are sought from dynamically enclosing contours.
;;;
;;; This does describe the behavior that we see. The "search" in the quoted
;;; paragraph refers to finding the appropriate handler within that single
;;; HANDLER-BIND. So when it says "the search continues", it's referring to
;;; examining other handlers within that same HANDLER-BIND. However, doesn't
;;; this directly contradict what CLHS 9.1.4 says?