The same underlying fault can produce wildly different outcomes depending on one thing: whether the system was built expecting it. A dependency times out; in one system that’s a handled case — the call is retried, then a cached value is served with a note that data may be stale, and a metric ticks up somewhere. In another system it’s an unhandled exception that propagates up through three layers, leaves a half-written record behind, and surfaces to the user as a blank page. Identical event, identical fault, completely different consequences. The difference isn’t in the failure. It’s in whether the system had somewhere to put it.

This is the thread’s throughline: error handling is a design decision, the error message is what the user sees of that decision, and both are downstream of a more basic question — did you think about this failure before it happened? Anticipated failures get a path: they degrade, they retry, they report clearly, they leave the system in a known state. Unanticipated failures get whatever the language does by default, which is rarely what you’d have chosen. The gap between the two isn’t heroic engineering; it’s mostly just having asked, at some point, “what happens when this doesn’t work?”

The useful move is to make that question routine rather than exceptional — attached to the moments where failure is most likely. Any time code crosses a boundary, the possibility of failure arrives with it: a network call, a disk write, a call into another team’s service, anything involving time or concurrency, anything involving input from outside. Those boundaries are where the interesting failures live, and they’re identifiable in advance without predicting anything specific. You don’t need to know the dependency will be slow next Tuesday. You only need to notice that it can be, and decide now what should happen then.

It’s worth being clear about what this isn’t. It isn’t handling every conceivable fault — some failures are rare and catastrophic enough that the right response is to crash cleanly rather than to limp along in a state nobody designed. That’s still a decision, and a legitimate one; the point is to make it deliberately rather than discover it during an incident. Nor is it about eliminating failure, which isn’t available. It’s about the difference between a system where failure is a designed state and one where failure is whatever falls out — and that difference shows up most sharply at exactly the moments when it matters most.

So: expect the boundaries to fail, decide in advance what should happen when they do, and write the message for the person who’ll be reading it under pressure. None of that prevents anything from breaking. What it changes is what breaking costs — whether a bad afternoon for one dependency becomes a bad afternoon for everyone who relies on you, or stays a small, legible, recoverable event that the system absorbed because someone thought about it first. Failure is not the exceptional case in software. It’s a permanent part of the operating environment, and the systems that hold up are the ones built as though that were true.