Le jeu. 16 mai 2019 à 20:58, Petr Viktorin
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.