[hunchentoot-devel] *catch-errors-p* and spurious stream errors patch (add your own implementation and shake).

[Vladimir Sedach]

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 at agharta.de> wrote:
> On Tue, 8 May 2007 01:34:51 +0200, Pierre THIERRY <nowhere.man at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>