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.do...@python.org> wrote: > 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/greg%40krypto.org >
_______________________________________________ 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
