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,