Don't Write Fallbacks

A fallback is a confession. It says: I expect this to fail, and when it does, I’ll quietly do something else. The something-else is almost never examined as carefully as the primary path, because by definition you reached it when you were already off the map.

The problem isn’t that fallbacks handle errors badly. It’s that they relocate the error — from the place where it happened to some later place where the symptom surfaces. A missing price becomes a zero, the zero becomes a return, the return becomes a risk number, and three layers downstream someone asks why the VaR looks wrong. The fallback didn’t fix anything; it laundered a known failure into an unknown one.

Delete the branch, not the bug

The alternative is to make the failure impossible to express. If a calculation requires a price and the price is absent, the type system — or a NotInvestigable result, or a fail-loud guard at the boundary — should stop you there, with full context, instead of letting a defaulted value flow onward.

This is what I mean by orthogonal design: instead of one path that mostly works and a second path that catches what the first missed, you build modules whose responsibilities don’t overlap, so an entire class of error has nowhere to live. You don’t catch the missing price. You arrange things so that “missing price” and “compute a return” can never be in the same room.

The cost is real, and it’s the point

Fallbacks feel cheaper because they let you ship without deciding what should happen. Orthogonal design forces the decision up front, at the boundary, where you still have the information to make it well. That up-front cost is not overhead — it’s the work. The fallback just defers the same work to production, at 2am, with less context.

Confidence that a fallback “handles it” is exactly the moment to be suspicious. If it truly handled it, you wouldn’t need the fallback.