Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exceptions raised in @app.route-decorated functions are passed to log.err twice #25

Closed
philmayers opened this issue Sep 17, 2013 · 4 comments
Labels

Comments

@philmayers
Copy link

The "processing_failed" function calls log.err on any exception:

https://github.com/twisted/klein/blob/master/klein/resource.py#L125

...but it also calls t.web Request.processingFailed which also calls log.err:

https://github.com/twisted/twisted/blob/trunk/twisted/web/server.py#L314

But the failure is also passed to log.err when the Deferred is garbage-collected.

This means errors/tracebacks are logged twice - not useful.

@philmayers
Copy link
Author

Actually that can't be quite right, because it calls return right after request.processingFailed. But I am seeing double-logging of tracebacks.

@philmayers
Copy link
Author

Ok, have checked the call stacks for the two log.err calls

One is in Request.processingFailed as above, the other is when the deferred is garbage-collected ("Unhandled error in deferred")

Since klein is generating the deferred for me here e.g.

@route('/foo')
def func(request):
return 'bar'

...gets wrapped by maybeDeferred, I can't add an errback to "eat" the deferred

@iffy
Copy link
Contributor

iffy commented Dec 21, 2013

@philmayers does the new handle_errors decorator let you achieve what you want? https://github.com/twisted/klein/blob/master/klein/app.py#L183

@brighid
Copy link
Contributor

brighid commented Sep 9, 2015

No comment from reporter: this probably is safe to close.

@glyph glyph closed this as completed Jul 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants