Event loop error handler

[GoogleCodeExporter]

There should be a per-event-loop settable callback to handle errors. This 
should be used to handle errors from at least the following:

- callbacks scheduled with call_soon/later/at
- I/O handlers set with add_reader/writer
- Tasks that raise an unhandled exception

(However other task/future failures shouldn't be handled; not sure about 
coroutines that fail when nobody's listening.)

The default should be to call logging.exception(), of course.

Original issue reported on code.google.com by gvanrossum@gmail.com on 24 Oct 2013 at 11:50

[GoogleCodeExporter]

Do you need help with this? I can take care of the implementation/tests (will 
need some help with the design)

Original comment by yseliva...@gmail.com on 5 Feb 2014 at 11:58

[GoogleCodeExporter]

Yes, I do need help with this -- but I can't help much with the design. Maybe 
Glyph has an opinion (this issue started when he remarked about this in a 
python-tulip thread) but I recommend first doing a strawman design and then 
posting it for review to the python-tulip list.

Original comment by gvanrossum@gmail.com on 6 Feb 2014 at 12:13

[GoogleCodeExporter]

Here's a link to the patch: http://codereview.appspot.com/61690043

Few thoughts (would be nice to hear your feedback):

- We may also want to add a 'severity' key to the 'context' dictionary.
This way it would be possible to use custom logging utilities for
warnings, notices, debug etc. If I recall correctly, Twisted has its 
own logging facility, so that's at least one real world example where
this may be needed.

- Instead of adding 'severity', we may provide an API for setting
custom logging API via the event loop policy.

- Instead of passing 'context', we may require exception callbacks to
have '**kwargs' in their signature (we can check that), and use normal
keyword arguments (for message and exception). That will make the
API a bit nicer to look at, but, yes, it's not a common practice to design
callbacks like that.

Original comment by yseliva...@gmail.com on 10 Feb 2014 at 6:53

[GoogleCodeExporter]

* I would keep it simple. No severity. Twisted's logging doesn't have it anyway.

* The context dict is much more robust than asking folks to support **kwds.

Original comment by gvanrossum@gmail.com on 11 Feb 2014 at 9:14

[GoogleCodeExporter]

The Patch Set 9 looks good to me.
https://codereview.appspot.com/61690043/#ps180001

You may just mention all availables keys in call_exception_handler() docstring:

- "message": Error message
- "exception" (optional): Exception object
- "future" (optional): Future instance
- "handle" (optional): Handle instance
- "protocol" (optional): Protocol instance
- "transport" (optional): Transport instance

Original comment by victor.s...@gmail.com on 18 Feb 2014 at 8:06

[GoogleCodeExporter]

This issue was closed by revision 0e7550b14e04.

Original comment by yseliva...@gmail.com on 18 Feb 2014 at 10:55

• Changed state: Fixed