Python 3.8 now has 3 hooks for uncaught exceptions:* sys.excepthook()* sys.unraisablehook()* threading.excepthook()_thread.start_new_thread() calls none of these hooks, but directly logs the exception.I propose to modify it to reuse sys.unraisablehook(): see attached PR.--Using threading.excepthook() would be another option, but _thread.start_new_thread() is usually wrapped in threading.Thread.run() which already uses threading.excepthook(). It might be surprising to see two bugs from the same thread using threading.excepthook().Moreover, right now, _thread is the "low-level" API to access threads: it doesn't acces threading. I'm not comfortable by adding an inter-dependency between _thread (low-level) and threading (high-level).If threading.Thread.run() is correctly written, it should not raise an exception. In the worst case, threading.excepthook should handle the exception. _thread.start_new_thread() should never get an exception raised by threading if threading.excepthook does correctly its job.

WithPR 13617, the function which raised the exception can be retrieved using unraisable.object.If we used threading.excepthook, I don't see how we could pass this function into threading.ExceptHookArgs: ExceptHookArgs.thread is expected to be a threading.Thread object.

This issue is a follow-up of:*bpo-36829: Add sys.unraisablehook() to custom how "unraisable exceptions" are logged*bpo-1230540: Add threading.excepthook() to handle uncaught exceptions raised by Thread.run()Discussions around _thread.start_new_thead() exception:Antoine Pitrou:"""From the doc: Handle uncaught :func:``Thread.run`` exception.What if some C extension wants to report uncaught exceptions in C-created threads? Does it have to create a dummy Thread object?For example, how about threads created by _thread.start_new_thread?"""https://github.com/python/cpython/pull/13515#issuecomment-495935350Serhiy Storchaka:"If we want to support low-level threads created by start_new_thread() we should call [threading.]excepthook() from t_bootstrap instead of Thread._bootstrap_inner. Otherwise implementing excepthook() as a Thread method would be more convenient."https://bugs.python.org/issue1230540#msg343748

> _thread.start_new_thread() calls none of these hooks, but directly logs the exception.It calls sys.excepthook() currently:import _threadimport threadingimport sysdone = Falsedef hook(*args):    global done    print(threading.current_thread())    done = Truesys.excepthook = hookdef worker():    raise Exception_thread.start_new_thread(worker, tuple())while not done:    pass

Output:---Unhandled exception in thread started by <function worker at 0x7fae27f212d0><_DummyThread(Dummy-1, started daemon 140385971111680)>---Ah right, sys.excepthook is called! But "Unhandled exception in thread started by <function worker at 0x7fae27f212d0>" line is always written into stderr, it cannot be avoided :-( And sys.excepthook doesn't provide access to the thread function which caused the issue.

I updated my PR description:_thread.start_new_thread() now logs uncaught exception raised by thefunction using sys.unraisablehook(), rather than sys.excepthook(), sothe hook gets access to the function which raised the exception.

> If threading.Thread.run() is correctly written, it should not raise an exception.Since the error handling for threading.Thread.run() is written on Python there are many opportunities to get an exception in error handling: KeyboardInterrupt, MemoryError and, at the shutdown stage, maybe NameError, AttributeError or TypeError.

> Since the error handling for threading.Thread.run() is written on Python there are many opportunities to get an exception in error handling: KeyboardInterrupt, MemoryError and, at the shutdown stage, maybe NameError, AttributeError or TypeError.Sure, the risk is real, but I tried to minimize it.NameError and AttributeError "should" not happen: I wrote _make_invoke_excepthook() to prevent name errors. Functions used to invoke threading.excepthook are "cached" in a private namespace. Moreover, the default hook is implemented in C also to reduce the risk of raising a new exception.Anyway, if threading.excepthook() raises a second exception, sys.excepthook() is now called to handle it ;-) That's a Python 3.8 change. In Python 3.7 and older, new exception was handled by start_new_thread().

New changeset8b09500345d998f3ff1e363a5210bc87f42ff306 by Victor Stinner in branch 'master':bpo-37076: _thread.start_new_thread() calls _PyErr_WriteUnraisableMsg() (GH-13617)https://github.com/python/cpython/commit/8b09500345d998f3ff1e363a5210bc87f42ff306

Thanks Serhiy for the review!