So the problem seems to be in READ-INITIAL-REQUEST-LINE where HANDLER-CASE* lets MAYBE-INVOKE-DEBUGGER handle the condition before the cases of the HANDLER-CASE.
I may well be missing something, but it seems like mabye HANDLER-CASE* should be changed as in the following patch so MAYBE-INVOKE-DEBUGGER is only invoked for unhandled conditions.
-Peter
--- conditions.lisp 2010-08-23 16:29:48.000000000 -0700 +++ fixed-conditions.lisp 2010-08-23 16:43:26.000000000 -0700 @@ -112,8 +112,8 @@
(defmacro handler-case* (expression &rest clauses) "Like HANDLER-CASE, but observes *CATCH-ERRORS-P*." - `(handler-case (with-debugger ,expression) - ,@clauses)) + `(with-debugger + (handler-case ,expression ,@clauses)))
(defun get-backtrace () "Returns a string with a backtrace of what the Lisp system thinks is
On Sun, Aug 22, 2010 at 11:27 PM, Hans Hübner hans.huebner@gmail.comwrote:
On Mon, Aug 23, 2010 at 07:26, Peter Seibel peter@gigamonkeys.com wrote:
If I set *CATCH-ERRORS-P* to NIL, is it expected/desired behavior that
the
timeout-errors generated when (I think) the client disconnects without making a full request or some such, will land you in the debugger?
This is a bug. Timeouts that occur while Hunchentoot is waiting for a new request should always be ignored. Timeouts that occur when a partial request has been request has been received _should_ be intercepted, though, as those are not part of a normal exchange.
I've added the issue to our bug tracker.
-Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel