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.com> wrote:
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



--
Peter Seibel
http://www.codequarterly.com/