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 :-( 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. I prefer to pass "raw" values and let the hook decides how to handle them :-) Said differently, I prefer to design the hook to restrict the risks of creating a new error. At least in the code which calls the hook. Inside the hook. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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
