STINNER Victor <vstin...@redhat.com> added the comment:
> Indeed, if you write your own Thread class, you can add a try...except > in the Thread.run() method. You don't need a dedicated > Thread.excepthook() method. Exactly. You can already do you best in your run() method to handle exceptions. threading.excepthook is only there is everything else already failed. FYI in my implementation, if threading.excepthook raises a new exception, it's also handled... by sys.excepthook this time ;-) > The only way a per-thread hook could be useful is if you could set it > *outside* of the Thread class (so not as a method), so that one can e.g. > catch / report exceptions raised in threads launches by third-party > libraries. I discuss threading excepthook with Pablo and he asked me if it would be possible to have a different behavior depending if the thread is spawn by my application or by "third party code". Using threading.excepthook, you can mark your threads that you spawn directly using a specific name, a special attribute, or you may even track them in a list (maybe using weak references). If sys.excepthook is used to handle threading exceptions, you call threading.current_thread(), but then we come back to the issue to "dying" Python: exception which occurs late in Python finalization, when most modules are already cleared and import no longer works. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1230540> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
