[hunchentoot-devel] usocket:timeout-errors and *catch-errors-p*

[Peter Seibel]

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)
-     , at clauses))
+  `(with-debugger
+     (handler-case ,expression , at 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 at gmail.com>wrote:

> On Mon, Aug 23, 2010 at 07:26, Peter Seibel <peter at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
Peter Seibel
http://www.codequarterly.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100823/eeb60b2c/attachment.html>