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

[Victor Stinner]

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()
case.

It seems like PyErr_WriteUnraisable() cannot avoid having 3 variables
(exc_type, exc_value, exc_tb), since they are not consistent as you
may expect.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.