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

Victor Stinner 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 (exctype, excvalue, exctb) 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.

More information about the Python-Dev mailing list