[Python-Dev] bpo-36829: Add sys.unraisablehook() (original) (raw)
Victor Stinner vstinner at redhat.com
Thu May 16 17:41:39 EDT 2019
- Previous message (by thread): [Python-Dev] bpo-36829: Add sys.unraisablehook()
- Next message (by thread): [Python-Dev] bpo-36829: Add sys.unraisablehook()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 :-(
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.
- Previous message (by thread): [Python-Dev] bpo-36829: Add sys.unraisablehook()
- Next message (by thread): [Python-Dev] bpo-36829: Add sys.unraisablehook()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]