STINNER Victor <vstin...@redhat.com> added the comment:
Ok, let me come back to the initial issue: Thomas Grainger: > Currently it's quite easy for these errors to go unnoticed. I'd like a way to > easily detect these in CI. nedbat suggested piping the process output to > another tool, and looking for 'Exception ignored in:' but this seems a little > diff When PyErr_WriteUnraisable() is called before Python finalization, my PR 13187 allows to handle these exceptions: log them in a dedicated file, abort the process, maybe even open a network connection, etc. The hook allows to implement your chosen behavior. The problem is more during Python finalization: see attached too_late_unraisable.py example and my previous comment. If PyErr_WriteUnraisable() is called after sys.stderr is closed or closed to None, the function does nothing: the exception is not logged. The question now becomes: do *all* calls to PyErr_WriteUnraisable() must abort the process? What is the point? Only a very low level debugger like gdb can be used to see the exception. @Thomas Grainger: Do you want to have to use gdb to trace such very level exception? IMHO sadly when PyErr_WriteUnraisable() is called way too late, we should simply ignore such exceptions. And so my PR 13187 is good enough to cover most cases. If someone cares about exceptions raised very late during Python finalization, Python finalization should be enhanced. But this code is very fragile and is not deterministic. It is a work in progress for years to enhance it. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36829> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
