Why doesn't sys.excepthook run when a threading.Thread's target raises?

### Why the main-thread hook cannot see it An exception travels up *one* call stack. `threading.Thread.start()` returns immediately; the target then runs on a stack of its own that begins in the threading module's bootstrap, not in the code that called `start()`. When the target raises and nothing in it catches the exception, the exception reaches the bootstrap frame — the top of *that* stack — and stops. The main thread may be somewhere else entirely, or already blocked in `join()`; either way it has no frame in that chain, so `sys.excepthook`, which is the main thread's last-chance step, is never consulted. ### What actually happens Since **3.8** the bootstrap calls `threading.excepthook(args)`. Note the signature difference from `sys.excepthook`: **one** argument, not three. It is a `threading.ExceptHookArgs` namedtuple with four fields: * `exc_type`, `exc_value`, `exc_traceback` — the familiar triple, and * `thread` — the `threading.Thread` object that died, so a report can name it. The default implementation, kept as `threading.__excepthook__`, prints `Exception in thread <name>:` followed by the traceback to `sys.stderr`. Then the thread terminates. Nothing else changes: sibling threads run on, `join()` returns normally, and the interpreter's eventual exit status is whatever the main thread produces — **0** for a program that otherwise finishes. That asymmetry is the whole interview point. Consider a nightly payment reconciliation job that fans work out to a pool of worker threads. One worker hits a partial-failure rollback and raises. The traceback lands in stderr among thousands of log lines, the job's exit status is 0, the scheduler records success, and the discrepancy surfaces three weeks later at the end of a release train. The fix is not to add a `try` around every target body — it is to make failure *visible and fatal at the process level*: ```python import sys, threading failed = threading.Event() def hook(args): failed.set() threading.__excepthook__(args) threading.excepthook = hook # ... start workers, join them ... if failed.is_set(): sys.exit(1) ``` ### Two things the hook is picky about **Do not keep the args object.** It holds the exception instance and the `Thread`, and the exception holds a traceback that holds frames that hold locals — including the thread itself. Storing `args` in a module-level list keeps dead threads and their entire frame state alive; the default hook deliberately drops the reference when it is done. Extract the strings, or the fields you need, and let the object go. **It is global, and it runs on the dying thread.** Your hook body executes on the worker, not the main thread, and it may be running while the interpreter is shutting down — at which point `sys.stderr` can already be closed and module globals torn down. Keep it short, and guard anything that touches I/O. ### The case where neither hook runs A callable submitted to `concurrent.futures.ThreadPoolExecutor` never triggers `threading.excepthook`, because the executor's worker catches the exception and stores it on the `Future` instead. It is re-raised only when someone calls the future's `result()` method, or returned by its `exception()` method. Fire-and-forget `submit()` with no retrieval is therefore *completely* silent — no traceback anywhere. The equivalent discipline is to keep the futures and iterate `concurrent.futures.as_completed`, calling `result()` on each so failures surface. `multiprocessing.pool.Pool` behaves the same way through its result objects. ### Which hook for which failure Complete coverage in a threaded service is: `sys.excepthook` for the main thread, `threading.excepthook` for workers, `sys.unraisablehook` for failures inside finalizers, and the asyncio event loop's exception handler if a loop is running. They are four separate installations, and installing one does nothing for the others. A quick way to check your wiring is to raise deliberately from each context in a smoke test and assert the report reached the sink. ### Before 3.8 Older interpreters printed the same message straight from the bootstrap with no override point, so libraries monkeypatched the thread class's `run` method to wrap it. That workaround is obsolete on any supported version, and a candidate proposing it today is showing their vintage.