The error handler is the least-exercised code in most systems, and it is the code that runs when things are already going badly. Everyone knows this in the abstract. What gets missed is that it isn’t a fixed condition you can address once — it’s a ratchet, and it tightens every time you make the system better.

Consider what reliability work actually does. You add a connection pool, so transient connection failures stop happening. You harden input validation upstream, so the malformed-record branch stops firing. You fix the retry policy, so the give-up path is reached less often. Each of these is a genuine improvement, and each of them reduces the frequency with which some other piece of code executes. The residual failures that still get through are, by construction, more exotic than the ones you eliminated. The paths that handle them are exercised less this quarter than they were last quarter, and less next quarter than this one.

Frequency of execution is doing more work than we usually credit. A path that runs constantly is under continuous audit by reality — it appears in profiles, its logs get read during unrelated investigations, its behavior lives in someone’s head because they watched it a hundred times. None of that is a process anybody scheduled; it’s a side effect of the code running where people can see it. A rare path gets none of it. It compiled, it passed review, and since that afternoon nothing has had an opinion about it. The inverted condition, the cleanup that runs twice, the log line that references a variable that’s nil by the time you reach it — all perfectly plausible on the screen, all uncorrected because nothing has ever been in a position to correct them.

Then there’s when it runs. A rare path executes under exactly the conditions that made it rare: the dependency is down, the disk is full, the payload is garbage, the region failed over. So the code with the least evidence behind it is the code that runs at the moment your margin for error is smallest, in front of an operator who has never seen its output before and is trying to read it under pressure. That isn’t bad luck. It’s what “rare path” means, stated plainly.

The response that doesn’t work is more review, because review is exactly the kind of attention this code already received and it wasn’t enough. What works is exercise — deliberately running the rare path on an ordinary schedule so it stops being rare. Restore the backup monthly, from the real artifact, into something you actually query. Force the fallback in staging on every deploy rather than waiting for the day it’s needed. Inject the fault. Write the test that asserts on the error string a human will read, not just on the fact that an error occurred. These find bugs, which is the advertised benefit, but the real one is subtler: they convert exceptional code into ordinary code, and ordinary code has people who know how it behaves.

None of that comes for free, which is the whole reason it doesn’t happen. Exercising a path you hope never runs costs real time and produces nothing visible, and the argument for skipping it is always available. But the alternative isn’t holding steady — it’s a slow drift where every improvement to the path you take makes the path you don’t take a little more foreign. Get good enough at this and you arrive somewhere genuinely strange: a system that almost never fails, whose every remaining failure happens in the part of it nobody has watched work.