
I'm playing with klein for a simple rest API (because I like the routing, mainly). When a method raises an exception, a traceback gets logged twice - once by the t.web Request.processingFailed, called from here: https://github.com/twisted/klein/blob/master/klein/resource.py#L125 ...and once by the deferred garbage collection, as Request.processingFailed doesn't eat the deferred: http://twistedmatrix.com/trac/browser/tags/releases/twisted-13.1.0/twisted/w... Obviously this double-traceback thing is hugely irritating. Who is at fault here? Is t.web doing the right thing by returning the failure from processingFailed, or is klein doing the wrong thing, either by using the (undocumented) processingFailed or omitting an errback further down the chain? Obviously there's no way for *me* to add an errback - klein generates the deferred for me.

On Sep 16, 2013, at 9:58 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
I'm playing with klein for a simple rest API (because I like the routing, mainly).
When a method raises an exception, a traceback gets logged twice - once by the t.web Request.processingFailed, called from here:
https://github.com/twisted/klein/blob/master/klein/resource.py#L125
...and once by the deferred garbage collection, as Request.processingFailed doesn't eat the deferred:
http://twistedmatrix.com/trac/browser/tags/releases/twisted-13.1.0/twisted/w...
Obviously this double-traceback thing is hugely irritating. Who is at fault here? Is t.web doing the right thing by returning the failure from processingFailed, or is klein doing the wrong thing, either by using the (undocumented) processingFailed or omitting an errback further down the chain?
Obviously there's no way for *me* to add an errback - klein generates the deferred for me.
Klein tracks bugs using Github. First, you should file a bug :-). <https://github.com/twisted/klein/issues> -glyph

On 09/17/2013 04:39 AM, Glyph wrote:
Klein tracks bugs using Github. First, you should file a bug :-).
Yes. The point of my email was to determine *which* system I should file a bug for (klein or t.web) as I was unsure who was at fault (returning the Failure from processingFailed doesn't seem terribly useful). But I will assume from your email that klein is at fault, and file a bug there. Cheers, Phil

On Sep 17, 2013, at 2:21 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 09/17/2013 04:39 AM, Glyph wrote:
Klein tracks bugs using Github. First, you should file a bug :-).
Yes. The point of my email was to determine *which* system I should file a bug for (klein or t.web) as I was unsure who was at fault (returning the Failure from processingFailed doesn't seem terribly useful).
But I will assume from your email that klein is at fault, and file a bug there.
Cheers, Phil
Sorry, I did not read your message carefully enough. Nevertheless, even if Klein isn't at fault, it's the "top layer" here, so a bug should be reported there. If we need to file a bug in Twisted too, having the Klein bug to link to for reference will be good as a practical example of the need for the fix :-). I also tend to assume that other people are like me, and will forget to write a bug and the bug will get lost, so a lot of my immediate replies end up being "file it file it file it" ;-). So it's good, just to quash that impulse of _mine_ if for no other reason, to start by filing a bug so it won't get lost, then start the mailing list thread by linking to the bug to prompt some action on it... For what it's worth, Klein isn't wrong to use processingFailed, because it doesn't start with a "_". Twisted is wrong for not documenting it :-). -glyph
participants (2)
-
Glyph
-
Phil Mayers