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

[Gregory P. Smith]

I like the feature, we should have it.  It'll be useful for debugging and
probably more.

Which brings me to the annoying paint color question: These exceptions were
most definitely raised. Thus the term "unraisable" is wrong. I believe you
really mean "uncatchable".

-gps

On Thu, May 16, 2019 at 4:00 PM Steve Dower <steve.dower at python.org> wrote:

> 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.
>
> Cheers,
> Steve
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190516/47e31641/attachment.html>