Let It Crash

Every developer knows that sinking feeling: you click a button, and nothing happens. No message, no error, no clue. The program just… does nothing. That’s what silent failure looks like — and it’s one of the worst things software can do.

When something goes wrong, a program should crash. Not because crashing is good, but because it’s honest. A crash is a signal that something unexpected happened. It tells you what went wrong, where it happened, and why. Silent failure hides all of that. It buries problems deep enough that you find them later, in the most confusing and indirect ways.

If you don’t know what to do in a particular situation, throw an exception. Don’t pretend that things are fine. Maybe it’s bad that you’re not ready to handle it properly, but at least you’re not lying to yourself. If you are prepared — if you truly know how to recover or at least report it meaningfully — then do it. Otherwise, let the program crash.

The same goes for exceptions. Don’t catch them just because you feel you have to. If you don’t know exactly what to do with an exception in this specific place, then don’t handle it there. Let it bubble up. Catch exceptions only at the very last moment — at the point where the process would otherwise die with an “uncaught exception” error.

Returning null or an empty result instead of throwing is often just another form of hiding the problem. It depends on context, of course. If a user has no profile picture, returning None makes sense. But if your banking service’s getBalance() call returns None, something is seriously wrong — and pretending it’s fine only makes things worse.

The “let it crash” mindset is about clarity, predictability, and respect. Respect for yourself, for your work, and for whoever will read your code later. Developers who fear crashes think in terms of “if users will be unhappy.” The ones who let it crash think “when users will be unhappy.” Users will be unhappy either way — but it’s better when they’re unhappy with a clear error message than when they’re lost in confusion.

Crashes are visible. They make noise. They tell you what needs to be fixed. Silent bugs stay in the shadows. Let your programs crash — it’s the fastest path to reliable software.