What does BrokenPipeError mean when a Python script writes to a pipe whose reader has exited?

## What the error actually reports A pipe has two ends, and the kernel will accept bytes on the write end only while at least one process still holds the read end open. When every reader closes — normally because the downstream program exited — the pipe is *broken*: there is no longer anyone who could ever consume what you are about to write. The `write` system call therefore does not block and does not quietly discard the data. It fails, and the error number it fails with is `EPIPE`, which is 32 on Linux and macOS. CPython inspects that errno and raises the exception mapped to it: `BrokenPipeError`, carrying the message `[Errno 32] Broken pipe`. The same errno arrives from sockets. Writing to a TCP connection whose peer has fully closed usually gives `ConnectionResetError` on the first attempt and `BrokenPipeError` on the next, because the peer's reset has by then torn the connection down locally. ## Where it sits in the exception hierarchy Since Python 3.3 the flat family of `IOError`/`socket.error` codes has been split into named `OSError` subclasses. `BrokenPipeError` is a direct subclass of `ConnectionError`; `ConnectionError` is a subclass of `OSError`. Practically: - `except BrokenPipeError` catches only this failure. - `except ConnectionError` also catches `ConnectionResetError`, `ConnectionAbortedError` and `ConnectionRefusedError`. - `except OSError` catches all of those plus every other operating-system error, which is usually too wide for a `pass`. The instance still carries the numeric code, so `err.errno == errno.EPIPE` remains a valid check; you rarely need it now that the class encodes the same information. ## The two situations that produce it The first is a producer in a shell pipeline. A script that streams many lines into a reader which stops after a handful — a pager the user quits, a filter that only needs the head of the stream — will keep writing into a pipe that no longer has a reader, and the next flush fails. The second is network code. A request handler that writes a large response to a client that disconnected mid-transfer sees exactly this exception. Here it is routine, not exceptional: on a busy server clients vanish all the time, and the correct handling is to log it at debug level and drop that connection, not to let it propagate. ## Why the traceback points at the wrong line When stdout is a terminal, Python's text layer is line-buffered. When it is a pipe, the layer underneath collects roughly 8 KB before issuing a syscall. So most `print` calls never touch the pipe at all. The one that raises is simply the one unlucky enough to trigger the flush that hits the dead reader, and it can be thousands of lines after the reader actually went away. Treat the reported line as "where the buffer happened to spill", not as the cause. It also means a program can finish its loop with data still buffered and only discover the broken pipe when the interpreter flushes the stream at exit. ## What it is not It is not an end-of-file condition. The reader of a closed pipe gets a zero-length read, which higher-level code surfaces as an empty string or `EOFError`; the *writer* of a pipe with no readers gets `EPIPE`. Confusing the two leads to except clauses that never fire. It is also not a Python-specific fault: every Unix program writing into a dead pipe hits the same kernel condition. What differs is Python's reaction to it, which is to raise rather than to let the process be killed. ## Handling it Decide whether the failure is fatal for this program. For a small filter, a broken pipe is normal and the right response is to stop writing and exit quietly. For a long-running service it is a per-connection event to be logged and swallowed. What is never right is a bare `except: pass` wrapped around the whole program, which hides genuine write failures such as a full disk. Catch the specific class, and catch it around the streaming loop rather than around each individual write.