On Sun, Nov 15, 2009 at 12:58, Edi Weitz <edi@agharta.de> wrote:
Yes, I agree. I was probably a bit too over-enthusiastic with the third bit... :)
Still, I only have a finite amount of time. The Hunchentoot-specific error handling was thrown out with the 1.0.0 release and if we add something similar back in, I want it to be a reasonable, working, flexible, and well-documented solution. That takes time, and I'll do it when I have that time, this being not a priority for me right now.
I have spent the last day working on a patch (incl. documentation) to include an error-handling mechanism in Hunchentoot, similar to the solution Peter posted some way up the thread (which was indeed a quick hack by me). This patch introduces an error handling protocol for connections and request handling. It introduces a new class and two new generic functions (all three exported and documented): * defclass debugging-acceptor: An acceptor that doesn't catch errors, instead relies on the implementation's debugger hook to catch the error and report it synchronously. * defgeneric invoke-process-connection-with-error-handling: An error handling mechanism for connection processing: Behavior for the regular hunchentoot:acceptor is the current default behavior. debuggable-acceptors only give you the debugger if their debug-connection-errors-p slot is non-NIL (NIL is the default) * defgeneric invoke-process-request-with-error-handling: An error handling mechanism for request handling: As before, the default behavior is in place for all subclasses of hunchentoot:acceptor except for debugging-acceptor. There, it invokes the debugger for signals raised with CL:ERROR. I hope very much that you find this worth including in the hunchentoot distribution. Of course, feedback is welcome. (-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs