`except Exception: continue` wraps each of 6,800 invoice rows in a nightly PDF renderer — what is wrong with that EAFP boundary?

### Why this pattern appears `try: ... except Exception: continue` around a loop body is written with good intentions: a nightly batch should not die on row 12 of 6,800 because one invoice has a malformed total. The instinct — keep going, do the work you can — is right. The implementation converts a partially-failing job into a silently-wrong one. ### Problem 1: the except clause is far wider than the failure it is for `Exception` is the base of essentially every error your code can raise. The handler is written to mean "this row's data is bad", but it also catches: - `AttributeError` and `TypeError` from a genuine bug in the renderer — a renamed field, a `None` where an object was expected; - `NameError` from a typo on a rarely-taken branch; - `MemoryError`, a broken database connection, an expired credential, a missing template file — failures that are about the *environment*, not the row; - `ImportError` from a lazily-imported optional module. Every one is relabelled "skip this invoice". The class of bug this creates is the worst kind: the program keeps running and produces plausible output, so no alert fires and no test fails. (It does *not* catch `KeyboardInterrupt` or `SystemExit`, which derive from `BaseException` rather than `Exception` — a bare `except:` would catch even those, which is why bare `except:` is worse still.) ### Problem 2: the try block is far wider than the failing call EAFP's discipline is that the `try` contains only the operation whose exception you are handling. When the whole loop body is inside it, an exception raised by the *logging* call, the output-path construction, or the progress counter is caught by a handler written for the renderer. You can no longer tell from the code which line the handler is for, and neither can a reader. Tightening the block is usually a one-line change and it restores the meaning: the `try` documents which call is expected to fail. ### Problem 3: a systemic failure looks exactly like a data failure This is the one that turns a bug into an incident. If the renderer cannot reach the database, or the PDF template was removed in a deploy, then all 6,800 rows raise the same exception. The loop skips all 6,800, finishes, and exits zero. Every downstream signal is green — the scheduler saw a successful run, the duration looks normal — and the only evidence is an empty output directory nobody looks at until someone asks where the invoices are. Per-row tolerance must therefore come with a **budget**. Track the failure count and the failure ratio; if every row fails, or the first N in a row fail, or the ratio crosses a threshold, raise and let the job fail loudly. A batch that tolerates 3 bad rows in 6,800 is resilient; a batch that tolerates 6,800 bad rows in 6,800 is broken and pretending. ### Problem 4: `continue` throws away the evidence A handler whose entire body is `continue` (or `pass`) discards the exception object and its traceback the moment the block ends. Nothing records which invoice failed or why, so the post-mortem starts from zero. Inside the handler you still hold the live exception, so capture it: - `logging.exception(...)` inside an `except` block, or `logger.warning(..., exc_info=exc)`, writes the full traceback; - `traceback.format_exc()` gives you the same text as a string if you want it in a structured record; - appending the row identifier and the exception to a failures list lets you emit one summary at the end and re-drive just those rows. ### What the corrected shape looks like ```python failures = [] for row in rows: try: pdf = render(row) # only the fallible call except (KeyError, ValueError) as exc: # only the data errors logger.warning('invoice %s skipped', row['id'], exc_info=exc) failures.append(row['id']) else: write(pdf) # happy path, cannot be misattributed if len(failures) > BUDGET: raise RuntimeError(f'{len(failures)} of {len(rows)} invoices failed') ``` Four changes carry all the value: the `try` shrank to one call, the `except` names the exceptions that genuinely mean "bad row", the handler records rather than discards, and the loop has a failure budget above which the job fails. ### Choosing which exceptions are "bad row" This is a design decision, not a lookup. Work out what the renderer's own contract raises for invalid input — often a small set of `ValueError`, `KeyError`, or a project-specific error class — and catch exactly that. If the set is uncomfortably broad, that is a signal the renderer should raise its own narrow exception at its boundary rather than leaking whatever its internals hit. When the honest answer is "ignore this specific exception and do nothing", `contextlib.suppress(ThatError)` says so in one line and names the exception, which reads far better than an empty `except` body. ### The interview point The question separates people who have run batch jobs from people who have only written them. The senior answer is not "never catch broadly" — it is that a per-item handler is a *policy* about tolerable failures, and a policy needs a named exception set, a record of what it swallowed, and a limit past which it stops being a policy and becomes a bug.