On 16May2019 1441, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 23:17, Steve Dower <steve.do...@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.
Cheers,
Steve
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
