Where does an exception raised inside a threading.Thread's target end up?

## A thread has no caller to raise into When a function raises, the exception travels up the call stack until something handles it. A thread's `run()` sits at the bottom of a *new* stack: there is nothing above it. `start()` returned long ago, and the thread that called it may be anywhere. So the exception cannot propagate — there is nowhere to propagate to. `threading`'s bootstrap wraps the call to `run()` in a `try`/`except`, and when something escapes it calls `threading.excepthook` with a single argument carrying four fields: the exception type, the exception instance, the traceback, and the `Thread` object itself. The default hook writes `Exception in thread <name>:` and the formatted traceback to `sys.stderr`, with one special case — `SystemExit` is ignored silently. Then the thread unregisters itself and ends, normally. ## What the owner sees: nothing This is the part that bites. From the starting thread's point of view a crashed worker and a completed worker are indistinguishable: * `t.is_alive()` becomes `False` either way. * `t.join()` returns `None` either way, and never re-raises. * The process exit status is unaffected: a program whose only worker died with an unhandled exception still exits `0`. * Wrapping `t.start()` in `try`/`except` catches nothing, because `start()` succeeded — the failure happened later, elsewhere. Take a background pick-list builder that does its imports lazily inside `run()` to keep startup fast, and a refactor that puts two of those modules in an import cycle. The worker dies on its very first call with an `ImportError`, a traceback goes to standard error, and the service carries on reporting itself healthy with a queue that quietly stops draining. In a container whose standard error is a firehose nobody reads, that traceback is the only evidence, and it is worth almost nothing. ## Making failure visible Three mechanisms, in ascending order of how much you should trust them. **Catch inside the worker.** The direct fix: wrap the body in `try`/`except Exception`, and record the outcome where the owner will look — an attribute on a `Thread` subclass, an entry appended to a list, an item on a channel the owner drains. The owner then checks that record after `join()` instead of assuming success. This is explicit and works with a bare `Thread`. **Let a pooled worker carry it.** Submitting the callable to a pool gives you a future object, which stores the exception and re-raises it when you ask for the result. That restores ordinary Python error handling at the call site, and it is the main reason to prefer pooled workers over hand-rolled threads for request-shaped work. **Install a process-wide hook.** Assigning your own callable to `threading.excepthook` gives you one place that sees every uncaught thread exception in the process, including ones from library threads you did not write. Use it to log through your logging configuration rather than to standard error, to add the thread's `name` and `native_id`, to bump a failure counter, and — for a worker whose death is fatal to the service — to set an `Event` that the supervising thread watches so the process can exit or restart the worker. It is a safety net for observability, not a replacement for handling errors where they happen: it cannot resume the dead thread or retry its work. ## Details worth knowing * `SystemExit` from a worker is swallowed by design, so `sys.exit(3)` in a thread terminates that thread and nothing else. If a worker's failure should end the process, it has to signal the main thread and let *that* thread exit. * The hook is a module-level attribute, so a library that reassigns it clobbers yours; set it once, early, and preserve the previous value if you want to chain to it. * The `Thread` object reaches the hook as one of the argument's fields, so a hook can identify which worker died and consult its attributes. * An exception inside your hook is itself unraisable and lands in the interpreter's unraisable-exception path, which is a bad place to end up — keep hook code short and defensive. * Custom `excepthook` code that keeps a reference to the exception keeps the traceback, and therefore the whole frame chain and every local in it, alive. Log the formatted text and drop the object rather than accumulating them. ## The habit Treat every thread body as a boundary that must not let an exception escape, exactly like a request handler. Wrap the body, record the outcome, decide who checks it, and add a process-wide `threading.excepthook` as the net for whatever you missed. The alternative is a service that keeps its liveness endpoint green while its workers die one by one.