Why does a Python filter that catches BrokenPipeError still print an error at exit?

## Two failures, not one A broken pipe produces two distinct write failures in a typical script, and they need different treatment. The first is the write inside your loop. Stdout to a pipe is block-buffered, so most `print` calls only fill an in-process buffer; eventually one of them spills the buffer to the pipe, the write fails with `EPIPE`, and `BrokenPipeError` propagates out of that `print`. An `except BrokenPipeError` around the loop catches this one cleanly. The second happens after your code has finished. At that point the buffer usually still holds bytes — the exception interrupted the flush partway, and anything printed since remains queued. During finalization CPython flushes the standard streams so that output is not lost. That flush writes to the same dead pipe and fails again, and this time there is no user frame anywhere on the stack to catch it. ## Why no except clause can help The finalization flush is not part of your program's control flow. There is no statement to wrap: the interpreter is tearing itself down. CPython treats the failure as an *unraisable* exception, the same category as an error inside a `__del__` method, and hands it to the unraisable hook, which prints a short report to stderr rather than a traceback. On 3.14 that report reads `Exception ignored while flushing sys.stdout:` followed by `BrokenPipeError: [Errno 32] Broken pipe`. The exact wording has changed across releases, so match on behaviour rather than on that string. The hook is a real extension point, and replacing it does suppress the message — but suppressing the report does not undo the failure, which brings us to the exit status. ## The 120 that overwrites your exit code When the interpreter cannot flush the standard streams during finalization, it reports the process failure with exit status **120**. This overrides whatever status your code asked for: a script that catches `BrokenPipeError` and calls `sys.exit(1)` still exits 120 when the buffer could not be drained. That is a genuine operational trap. A supervisor or job runner keyed on specific exit codes sees an unfamiliar 120 rather than the 1 you intended, and 120 is easily mistaken for something the program itself defined. ## The fix that actually works Make the final flush succeed by giving it somewhere harmless to write. In the handler, open the null device and duplicate that descriptor over file descriptor 1, the descriptor stdout writes through. The buffered bytes are then flushed into nothing, finalization succeeds, no ignored-exception message is printed, and your chosen exit status survives: ```python except BrokenPipeError: os.dup2(os.open(os.devnull, os.O_WRONLY), 1) sys.exit(1) ``` This is the shape the standard library's own documentation recommends for the broken-pipe case, and it is worth understanding rather than copying: you are not hiding the error, you are removing the reason the shutdown flush would fail. A second option is `os._exit`, which terminates immediately without running finalization at all. It certainly avoids the message, and it lets you choose the exit status, but it also skips `atexit` handlers and the flushing of every *other* open file. Use it only when you know nothing else needs to be written. What does not work is catching the exception and returning normally, or replacing the unraisable hook and calling the problem solved. The first leaves the buffer full and gets you the 120; the second silences the report while still getting you the 120. ## Diagnosing it in the wild The signature is unmistakable once you know it: a program that appears to handle broken pipes correctly, produces the right output, and yet exits 120 with a one- or two-line stderr complaint that is not a traceback. The absence of a traceback is the clue — a traceback means the exception escaped your code; an `Exception ignored` line means it escaped the *interpreter's* code, after yours had finished. Check whether stdout is a pipe, whether the writer buffers, and whether the handler leaves the stream in a state the final flush can survive.