[Python-Dev] bpo-36829: Add sys.unraisablehook()

Steve Dower steve.dower at python.org
Thu May 16 19:00:07 EDT 2019

On 16May2019 1441, Victor Stinner wrote:
> Le jeu. 16 mai 2019 à 23:17, Steve Dower <steve.dower at python.org> a écrit :
>> You go on to say "pass an error message" and "keep repr(obj) if you
>> want", but how is this different from creating an exception that
>> contains the custom message, the repr of the object, and chains the
>> exception that triggered it?
> Well, "unraisable exceptions" are raised when something goes wrong.
> I'm not comfortable with creating a new exception instance and
> chaining it to the previous exception, because it could go wrong and
> raise a 3rd exception. Issue a new error while trying to log an error
> can be annoying :-(

I mean, aren't they all? :) That's why they're exceptional.

If we're not in a position to raise a new exception, then it's not safe 
to call into user's Python code. If it's safe to call into their Python 
code, then we have to be in a position to raise a new exception.

You said earlier that we can safely do this, and now you're saying we 
can't safely do it. Which is it?

> Moreover, when I looked at details of the "unraisable exception" (see
> my reply to Petr Viktorin), I saw that the exception is not well
> defined as you might expect. (exc_type, exc_value, exc_tb) can *not*
> be replaced with (type(exc_value), exc_value,
> exc_value.__traceback__). Sometimes, exc_value is None. Sometimes,
> exc_tb is a traceback object, but exc_value.__traceback__ is None. So
> I'm not comfortable neither to chain such badly shaped exception into
> a new exception.

Yeah, this is the normal optimization for raising and handling 
exceptions that never reach Python code. Exceptions are supposed to be 
normalized before re-entering the eval loop.

> I prefer to pass "raw" values and let the hook decides how to handle them :-)

This is fine, it's how we handle exceptions in most other places (such 
as __exit__, logging, sys, traceback and all through the C API), and 
skipping normalization for a last-chance "the-world-may-be-burning" hook 
isn't the worst thing ever.


More information about the Python-Dev mailing list