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

Refactor the return handler #71

Open
tvoinarovskyi opened this issue Mar 20, 2016 · 1 comment
Open

Refactor the return handler #71

tvoinarovskyi opened this issue Mar 20, 2016 · 1 comment
Milestone

Comments

@tvoinarovskyi
Copy link
Contributor

Currently the return handler ( Channel.set_return_handler ) has a strange default. From docs:

By default, an exception is raised, which will be handled by the event loop’s exception handler (see BaseEventLoop.set_exception_handler). If handler is None, this default behaviour is set.

This is bad practice, and the documentation should not recommend using BaseEventLoop.set_exception_handler it in any way. I think a null handler, that just logs the return is more sensible.

@tvoinarovskyi
Copy link
Contributor Author

set_exception_handler is not a signal, it's a handler (ie we can't set multiple handlers, just override it). It's not designed to perform application logic, but for logging, alerting, etc. It should react on unexpected problems, rather than expected callbacks.

@benjamin-hodgson benjamin-hodgson added this to the v0.6 milestone May 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants