On 2/6/2014, 1:24 PM, Guido van Rossum wrote:
On Thu, Feb 6, 2014 at 8:53 AM, Yury Selivanov <[email protected]>wrote:
As discussed with Guido in issue #80
(https://code.google.com/p/tulip/issues/detail?id=80),
I'm proposing a strawman design for having a user definable event loop
handler for unhandled exceptions.
Two new API points:
- "loop.set_exception_handler(callback)"
Sets 'callback' as a new unhandled error handler for the event loop
'loop'. The signature of callback should be '(loop, exception,
context)'
where: 'loop' parameter is the current event loop running; 'exception'
is the unhandled exception object; 'context' is a string (str),
that will be the basic context information, like
"unhandled exception in add_reader callback" (the kind of information
that usually goes to the log title).
I'd rename the context arg to 'message', then you don't have to explain
what it is. :-)
Agree. Need to make it clear, though, that 'message' is not
necessarily the same as 'exception.args[0]'
Also I'd steer clear from calling the handler 'callback' -- maybe just name
it 'exception_handler'?
It's OK to call 'loop.stop()' or 'loop.call_*' methods from the
handler.
Cool.
If a user set handler raises an exception, that exception will be
handled by the default event loop exception handler (that will
simply log it)
Nice.
- "loop.restore_default_exception_handler()"
Restores exception handler to the default one.
Default exception handler just logs the error with
'loop.logger.exception()'
Maybe instead of having a separate API for this rarely-used action, this
could be spelled as loop.set_exception_handler(None)?
Good. Since we always need to have at least default exception
handler, using None in this context seems very logical.
A few questions:
- Do we need an API to ask the loop for its current exception handler?
I thought about this, and my reasoning for not proposing
'loop.get_exception_handler()' was to keep the API simple.
Besides, let's pretend we have this API in place, and you
can get the current handler. The getter will return the handler
to the caller, and that handler, or callback object will make
sense only to the application/code that set it in the first
place. And I think in this case, it's better to force the client
code to carefully use and track the calls to
'set_exception_handler()'.
If
so, what should it return if no handler is set explicitly?
If we make the default handler a public API, then we can return
a bound method. If we decide to hide it -- then 'None'.
- Should we allow multiple exception handlers, or just one? (I'd prefer
just one.)
The API will be more complex then, as we'll need functions to
remove exception handlers, at least. Applications can always
set one handler that will call other functions (as many as they
need).
- Should we have a way to invoke the default handler explicitly? E.g. if
the user's handler doesn't want to do anything special, they could pass it
to the default handler instead of having to figure out how the default
handler logs things.
I think it's a good idea to let users trigger the default handler
somehow.
One option is to add it to the public API. But it may cause some
confusion about when you should use it. Basically, the only place
it should be used in, is a custom exception handler.
Another option would be to let the custom handler simply re-raise
the exception, but this way we'll mix exceptions originated *in*
the handler with other exceptions, so I'd be -1 on this approach.
And another option is to establish a protocol: if a custom handler
returns an exception object, that object is passed to the default
handler.
- Should we have a way to invoke the current handler explicitly? E.g. if
there's user code that has encountered an exception and it wants that
exception to be treated the same as the loop handles other exceptions.
-1 on this. Non-sophisticated code should just stick to the logging
module. The kind of code that uses its custom error handlers, can
develop its own facilities for error reporting.
Yury
