[Python-Dev] bpo-36829: Add sys.unraisablehook()
vstinner at redhat.com
Thu May 16 16:22:00 EDT 2019
Le jeu. 16 mai 2019 à 20:58, Petr Viktorin <encukou at gmail.com> a écrit :
> I always thought the classic (exc_type, exc_value, exc_tb) triple is a
> holdover from older Python versions, and all the information is now in
> the exception instance.
> Is the triple ever different from (type(exc), exc, exc.__traceback__)?
> (possibly with a getattr for __traceback__)
I added assertions in PyErr_WriteTraceback():
assert(Py_TYPE(v) == t);
assert(PyException_GetTraceback(v) == tb);
"Py_TYPE(v) == t" fails in
test_exceptions.test_memory_error_in_PyErr_PrintEx() for example.
PyErr_NoMemory() calls PyErr_SetNone(PyExc_MemoryError), it sets
tstate->curexc_type to PyExc_MemoryError, but tstate->curexc_value is
set to NULLL.
"PyException_GetTraceback(v) == tb" fails in
test_exceptions.test_unraisable() for example: "PyTraceBack_Here(f);"
in the "error:" label of ceval.c creates a traceback object and sets
it to tstate->curexec_traceback, but it doesn't set the __traceback__
attribute of the current exception.
> Should new APIs use it?
I tried to add a "PyErr_NormalizeException(&t, &v, &tb);" call in
PyErr_WriteUnraisable(): it creates an exception object (exc_value)
for the PyErr_NoMemory() case, but it still doesn't set the
__traceback__ attribute of the exception for the PyTraceBack_Here()
It seems like PyErr_WriteUnraisable() cannot avoid having 3 variables
(exc_type, exc_value, exc_tb), since they are not consistent as you
Night gathers, and now my watch begins. It shall not end until my death.
More information about the Python-Dev