Crashing Early on Purpose So You Never Guess Later
Two halves, pulling in opposite directions. Fail fast says: stop dead the instant an assumption is violated. Fallback grace says: keep serving something rather than propagating a failure to the user. Applied at the wrong layer, each one is a bug. The rule that reconciles them is not technical — it is about who owns the mistake.
The two halves
Fail fast — inside
- Validate at the boundary, not deep in the call stack
- Check the argument on entry; assert the invariant
- Throw where the bad value entered the system
- Loud, immediate, unrecoverable
Fallback grace — edge
- Partner service slow, cache cold, network flaky
- Degrade to a stale value or a reduced feature
- Don't propagate the world's failure to the user
- Deliberate, bounded, and always signalled
A programming error is yours — fail fast and loudly. An environmental failure is the world's — degrade deliberately. Ask who owns the mistake, and the layer answers itself.
Why failing early is cheaper
The cost is diagnostic distance. A bug that surfaces far from its origin spends most of its debugging time in travel — you read a stack trace that names the place the value finally broke something, not the place it came from. By then the frame that could have told you the cause has already returned.
Throwing at the boundary collapses that distance to zero. The trace names the caller who passed the bad value. There is nothing left to guess.
Key components
Boundary validation
Arguments and inputs are checked on entry. Bad data never gets to travel.
Invariant assertion
The thing that must always be true is stated in code, so violating it is loud.
Deliberate degradation
A named, bounded reduced mode at the edge — stale cache, partial feature — not an accident.
Fallback telemetry
Every degraded path increments something. A silent fallback is indistinguishable from health.
Where this gets shipped wrong
A catch block that swallows the exception and returns an empty list turns a loud failure into a page that renders zero results and looks fine. Nothing is red. Nothing pages. The incident is discovered by a customer, days later, and by then you are reconstructing what happened from logs that never recorded it.
The fix is one line of discipline: every fallback must emit a signal that it fired. A counter, a log line at warn, a span attribute — something that moves. catch (e) { return [] } is not a fallback. It is data loss with good manners.
How to apply it
- Draw the line. Mark where your code ends and the world begins — the call to a partner service, the cache read, the disk. Inside that line is yours; outside it is not.
- Inside the line, fail fast. Validate on entry, assert invariants, throw at the boundary. Never catch your own bug to keep the request alive.
- Outside the line, degrade deliberately. Decide in advance what the reduced answer is: last known value, cached page, feature hidden. Write it down, don't improvise it in a catch.
- Make every fallback emit. Increment a metric, log at warn with the reason. If it fires and nothing moves, you have built a blind spot.
- Test the failure, not the success. Force the dependency down and check that a metric moved — not merely that the page still loaded. A page that loads is exactly what the broken version does too.
Where you meet it
recs_fallback_total ticks up every time.Checkpoint — answer before you move on
- What single question decides whether a given failure should fail fast or fall back? Hint: it is about ownership, not severity.
- Why does throwing three layers deeper than the boundary cost you more debugging time, even when the exception message is identical? Hint: name the quantity — what has grown between origin and surface?
- A fallback returns an empty list when the search service is down, and the page renders cleanly. Describe the test that proves this fallback is safe — and explain why "the page still loaded" fails that test. Hint: something other than the page has to move.