In asyncio, what reports an exception from a task nobody ever awaited?

### Where the exception actually goes A coroutine object does nothing on its own; something must drive it. When `asyncio.create_task` wraps one in an `asyncio.Task`, the task steps the coroutine, and if the coroutine raises, the task **captures** the exception and completes in the failed state. Nothing propagates: the loop keeps running, `sys.excepthook` is never involved, and the error sits inside the task waiting for someone to ask for it. Awaiting the task, or calling its `result()` or `exception()` method, are the ways of asking. If nobody asks, CPython still does not want to lose the error. The task's finalizer notices it holds an unretrieved exception and calls the loop's `call_exception_handler` with a context dictionary containing at least: * `message` — `"Task exception was never retrieved"`, * `exception` — the exception instance, * `future` or `task` — the object involved. The default handler formats that and logs it to the `asyncio` logger at error level. Two consequences follow immediately. First, the report arrives **whenever the object is collected**, not when the failure happened — potentially much later, potentially never if the process exits first. Second, if the application configured logging so that library loggers are quiet, the report is dropped entirely. ### Installing your own handler The handler is a property of a loop, not of the process. You set it by calling the running loop's `set_exception_handler` method with a callable of two arguments: ```python import asyncio def handler(loop, context): exc = context.get("exception") print(context["message"], repr(exc)) async def main(): asyncio.get_running_loop().set_exception_handler(handler) ... asyncio.run(main()) ``` Because `asyncio.run` creates a new loop for each call and closes it afterwards, a handler installed once at import time attaches to nothing. Install it as the first statement of your entry coroutine, or use `asyncio.Runner` (**3.11**) with a `loop_factory` so the handler is in place before any user code runs. Passing `None` restores the default handler; the default is also directly callable through the loop's `default_exception_handler` method, which is the polite way to keep standard output while adding your own reporting. The same handler receives more than unretrieved task exceptions: failures inside callbacks scheduled with the loop's `call_soon`, transport and protocol errors, and other places where the loop has an error but no caller to give it to. It is asyncio's analogue of `sys.unraisablehook` — the channel for failures with nobody to propagate to. ### Why not to depend on it A payment reconciliation job that fans out one task per account is the classic shape of this bug. A partial-failure rollback raises inside one task, the job never awaits that task — or awaits it in a `gather` whose result it discards — and the process exits 0. The stderr log gains one `Task exception was never retrieved` line, or none at all if the task was still referenced at shutdown, and the discrepancy is found three weeks later during the release train. The robust practices are structural, not hook-based: * **Keep a strong reference to every task you create.** The loop does not hold one for you after completion; a task whose only reference you dropped can be collected mid-flight, which is the well-known "task disappeared" surprise. Store them in a set and discard on done. * **Retrieve every result.** `await`, `gather`, or a done callback that calls the task's `exception()` method — anything that reads the outcome turns an invisible failure into a real one. * **Prefer structured concurrency.** `asyncio.TaskGroup` (**3.11**) waits for its children and re-raises their failures as an `ExceptionGroup`, so "nobody retrieved it" stops being possible for tasks inside the group. Use the loop exception handler as the **safety net** underneath those — wired to the same sink as `sys.excepthook`, `threading.excepthook` and `sys.unraisablehook`, so that whatever slips past structured handling is still recorded rather than printed into the void. ### The four-hook picture An async service that wants no silent failures installs all four: the main-thread hook for the process's own crash, the threading hook for anything run in an executor thread that is not a future-based worker, the unraisable hook for finalizers, and the loop handler for the async side. Each is a separate installation, and the loop one must be repeated per loop.