[hunchentoot-devel] *catch-errors-p* and spurious stream errors patch (add your own implementation and shake).
Hello,
While debugging a web application, the need to not catch errors became apparent. Unfortunately, there are spurious stream errors that make this less than useful currently (someone has informed me that this problem is well known). The attached patch is my proposal to let people deal with this and take advantage of (setf *catch-errors-p* nil). If you think this is the wrong way of going about things, please let me know.
Thanks, Vladimir
On Mon, 7 May 2007 14:52:27 -0600, "Vladimir Sedach" vsedach@gmail.com wrote:
While debugging a web application, the need to not catch errors became apparent. Unfortunately, there are spurious stream errors that make this less than useful currently (someone has informed me that this problem is well known). The attached patch is my proposal to let people deal with this and take advantage of (setf *catch-errors-p* nil).
I had thought that the changes in 0.9.0 made the spurious time-out errors go away. Are you using the newest version? Which errors do you see exactly? Can you send a backtrace?
If you think this is the wrong way of going about things, please let me know.
If this is really still a problem, I'd like to release a patch for all supported implementations.
Thanks, Edi.
Scribit Edi Weitz dies 08/05/2007 hora 00:05:
If this is really still a problem, I'd like to release a patch for all supported implementations.
I'm not sure why there would be a need to use an implementation specific condition, as CL provides stream-error (which is a superclass of the SBCL specific condition used in the patch).
diff -r 1ad0d5aa26ef packages.lisp --- a/packages.lisp Tue May 01 19:14:06 2007 +0200 +++ b/packages.lisp Tue May 08 01:30:13 2007 +0200 @@ -131,6 +131,7 @@ :+http-unsupported-media-type+ :+http-use-proxy+ :+http-version-not-supported+ + :always-catch-stream-errors :authorization :aux-request-value :content-length diff -r 1ad0d5aa26ef util.lisp --- a/util.lisp Tue May 01 19:14:06 2007 +0200 +++ b/util.lisp Tue May 08 01:28:49 2007 +0200 @@ -100,10 +100,16 @@ are discarded (that is, the body is an `(let (,,@temps) ,,@body))))))
-(defun maybe-invoke-debugger (condition) - "Invokes the debugger with CONDITION if *CATCH-ERRORS-P* is NIL." +(defgeneric maybe-invoke-debugger (condition) + (:documentation "Invokes the debugger with CONDITION if *CATCH-ERRORS-P* is NIL.")) + +(defmethod maybe-invoke-debugger (condition) (unless *catch-errors-p* (invoke-debugger condition))) + +(defun always-catch-stream-errors () + (defmethod maybe-invoke-debugger :around ((condition stream-error)) + nil))
(defmacro with-debugger (&body body) "Executes BODY and invokes the debugger if an error is signaled and
But maybe that's still a quick and dirty fix for the problem. Maybe a way to add and remove classes of conditions to catch would be better...
Doubtfully, Pierre
Oops, I didn't write a docstring for the new function:
diff -r 1ad0d5aa26ef packages.lisp --- a/packages.lisp Tue May 01 19:14:06 2007 +0200 +++ b/packages.lisp Tue May 08 01:30:13 2007 +0200 @@ -131,6 +131,7 @@ :+http-unsupported-media-type+ :+http-use-proxy+ :+http-version-not-supported+ + :always-catch-stream-errors :authorization :aux-request-value :content-length diff -r 1ad0d5aa26ef util.lisp --- a/util.lisp Tue May 01 19:14:06 2007 +0200 +++ b/util.lisp Tue May 08 01:36:51 2007 +0200 @@ -100,10 +100,17 @@ are discarded (that is, the body is an `(let (,,@temps) ,,@body))))))
-(defun maybe-invoke-debugger (condition) - "Invokes the debugger with CONDITION if *CATCH-ERRORS-P* is NIL." +(defgeneric maybe-invoke-debugger (condition) + (:documentation "Invokes the debugger with CONDITION if *CATCH-ERRORS-P* is NIL.")) + +(defmethod maybe-invoke-debugger (condition) (unless *catch-errors-p* (invoke-debugger condition))) + +(defun always-catch-stream-errors () + "Adds an around method on MAYBE-INVOKE-DEBUGGER to always catch stream-related errors." + (defmethod maybe-invoke-debugger :around ((condition stream-error)) + nil))
(defmacro with-debugger (&body body) "Executes BODY and invokes the debugger if an error is signaled and
Correctively, Pierre
On Tue, 8 May 2007 01:34:51 +0200, Pierre THIERRY nowhere.man@levallois.eu.org wrote:
I'm not sure why there would be a need to use an implementation specific condition, as CL provides stream-error (which is a superclass of the SBCL specific condition used in the patch).
Agreed.
+(defun always-catch-stream-errors ()
- (defmethod maybe-invoke-debugger :around ((condition stream-error))
- nil))
I think nesting a DEFMETHOD within a DEFUN is bad style. There's also no way to revoke this.
But, first of all, I'd like to wait for the OPs answers to my questions anyway.
Thanks, Edi.
It turns out the error I'm getting is actually a connection-reset-by-peer (although SBCL doesn't give the proper clues for this - Allegro does). In fact it's a subtype of stream-error on Allegro as well, so I think Pierre's approach to ignoring stream errors is the right one.
The question that remains for me, is setting *catch-errors-p* to nil the right way to debug applications built on Hunchentoot? It seems to me the answer is 'yes', since they can potentially be tightly coupled (for example, right now we're doing an :around on dispatch-request to add functionality for our application). Making maybe-invoke-debugger a generic function so you can specialize on the condition (ignore the :around in my patch, I was being stupid) seems like an outgrowth of this approach.
Vladimir
On 5/8/07, Edi Weitz edi@agharta.de wrote:
On Tue, 8 May 2007 01:34:51 +0200, Pierre THIERRY nowhere.man@levallois.eu.org wrote:
I'm not sure why there would be a need to use an implementation specific condition, as CL provides stream-error (which is a superclass of the SBCL specific condition used in the patch).
Agreed.
+(defun always-catch-stream-errors ()
- (defmethod maybe-invoke-debugger :around ((condition stream-error))
- nil))
I think nesting a DEFMETHOD within a DEFUN is bad style. There's also no way to revoke this.
But, first of all, I'd like to wait for the OPs answers to my questions anyway.
Thanks, Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, 8 May 2007 13:43:59 -0600, "Vladimir Sedach" vsedach@gmail.com wrote:
Making maybe-invoke-debugger a generic function so you can specialize on the condition (ignore the :around in my patch, I was being stupid) seems like an outgrowth of this approach.
Yes, that makes sense. I've made a new release where MAYBE-INVOKE-DEBUGGER is an exported generic function.
Thanks, Edi.
-
Edi Weitz -
Pierre THIERRY -
Vladimir Sedach