On Fri, Feb 20, 2009 at 12:34, Jochen Schmidt jsc@crispylogics.com wrote:
*BREAK-ON-SIGNALS* is better than what Hunchentoot previously had - You're sent to a the debugger, making actual analysis possible, and the technique works everywhere, not just in Hunchentoot.
Thats actually not a feature. With *catch-errors-p* you ended up within an debugger too and it was actually a good thing that it was restricted to hunchentoot. *break-on-signals* is definitely the wrong tool to do that! Following the dev-tree for some time now I have just setup my own error handling using handler-bind in a custom dispatcher
- similar to what Edi outlined in his answer. It should at least be
documented how to properly install such a hunchentoot specific error- handler, because it might not be obvious to everyone. The new hunchentoot is meant to be more customizable - it actually is, because of fantastic the merits of CL like handler-bind - It would have been nicer (from a library designer perspective) to have this integrated within the protocols though.
So, I just spent a few hours (successfully) hemming and haw-ing about how to put these suggestions into real code, and this is what I came up with:
;;; An acceptor that invokes the debugger on errors: (defclass debuggable-acceptor (hunchentoot:acceptor) ())
(defmethod process-connection ((*acceptor* debuggable-acceptor) (socket t)) (declare (ignore socket)) (handler-bind ((error #'invoke-debugger)) (call-next-method)))
(defmethod acceptor-request-dispatcher ((*acceptor* debuggable-acceptor)) (let ((dispatcher (call-next-method))) (lambda (request) (handler-bind ((error #'invoke-debugger)) (funcall dispatcher request)))))
In my development system, I then do (make-instance 'debuggable-acceptor :port 4242) instead of 'hunchentoot:acceptor, and error conditions pop up a swank debugger again.
Hope this is useful for everyone else,