How would you use sys.excepthook so unhandled tracebacks stop reaching users?

## What sys.excepthook is When an exception propagates out of the top-level code of the **main** thread, CPython does not print the traceback itself. It calls `sys.excepthook(exc_type, exc_value, traceback_object)`. The default implementation formats and writes to `sys.stderr`, and the pristine original is preserved as `sys.__excepthook__` so you can delegate to it or restore it. Because it is just an attribute, a process can install its own at startup: ```python import sys, traceback, uuid def hook(exc_type, exc, tb): ref = uuid.uuid4().hex[:8] audit_log.error("crash ref=%s\n%s", ref, "".join(traceback.format_exception(exc_type, exc, tb))) print(f"the import failed; quote reference {ref}", file=sys.stderr) sys.excepthook = hook ``` This is the process-wide equivalent of the error boundary you put around a request handler, and it is what catches the cases the boundary missed: a failure during startup before any handler exists, a crash in a batch entry point, an error raised while shutting down. For a museum-catalogue importer run as a scheduled job, the difference is whether the shared operations console shows a full traceback with source lines, install paths and a driver error containing the connection string, or one line and an id. ## The blind spots — this is the senior half of the answer An interviewer is really asking whether you know where the hook *does not* run. * **Other threads.** An exception escaping a thread's `run` never reaches `sys.excepthook`; it goes to `threading.excepthook`, introduced in 3.8, and the default prints the traceback to stderr with the thread name. A process that installs only `sys.excepthook` and then does its work in a worker thread has changed nothing about what gets printed. * **Finalization.** An exception raised in `__del__`, in a weakref callback, or during interpreter shutdown cannot be propagated. It is routed to `sys.unraisablehook` instead, also 3.8. These leak quietly, at the worst possible time, when your logging may already be torn down. * **Anything already caught.** The hook is the top of the propagation path. Code that catches an exception and prints it, or returns it in a response, never gets there. Installing the hook does not retroactively make sloppy inner handlers safe. * **A child process.** Every interpreter has its own `sys.excepthook`; a worker started under a process-based executor does not inherit the parent's installed hook through every start method, so hook installation belongs in the worker's entry point, not only in the parent's. * **Faults below Python.** A segmentation fault or a hard abort in native code bypasses the hook entirely; that output comes from the fault handler, not from `sys`. ## sys.tracebacklimit, and why it is not a control `sys.tracebacklimit` is an integer attribute that is **not defined by default**; setting it changes how many frames the interpreter's default display prints. Setting it to `0` (or a negative value) reduces the output to just the exception type and message, with no "Traceback (most recent call last):" header at all. Three things make it the wrong tool for disclosure: 1. **It keeps the wrong end.** With `sys.tracebacklimit = 1` on 3.14, the frame you keep is the innermost one — nearest the failure — which is typically the most revealing. (This is the opposite of `traceback.print_exception(exc, limit=1)`, whose positive limit keeps the outermost frame; the interpreter's default display and the `traceback` module's limit count from different ends.) 2. **It leaves the message.** The exception type and its message survive at any limit, and the message is frequently where the path, the DSN or the offending value lives. 3. **Nothing else obeys it.** Any code path that calls `traceback.format_exc()` itself — your own boundary, a library's error reporter, a debug page — produces a full traceback regardless. So use it, if at all, as a tidiness knob for a CLI where a deep stack is noise for the user. Do not present it as a hardening measure; the hardening is the hook plus the handler policy. ## Putting it together A hardened entry point does four things before it does any work: installs `sys.excepthook`, installs `threading.excepthook`, installs `sys.unraisablehook`, and configures the log sink they all write to. Each of them formats the traceback into that sink and emits only a reference outward. Then the error boundary inside the request path does the same thing with the same id scheme, so support has one lookup regardless of where the failure surfaced. Restoring `sys.__excepthook__` in tests keeps the real traceback visible where you want it.