30. Crash Early

If a value in your application is invalid, let it fail immediately.

Not later. Not somewhere deep in the flow. Not silently. Right away.

Suppose a function only expects the values 1, 2, or 3, but somehow 4 gets passed in. Then something is wrong. At that point, your application is already in a state you did not intend. That is not the moment to try to "just keep going." That is the moment to throw an error.

Why? Because the problem already exists.

If it does not crash there, it will probably crash somewhere else later on. And in that other place, it is often much less clear what the real cause was. Then you are no longer solving the problem itself — you are spending your time trying to trace where it started. 🔍

Even worse: sometimes it does not visibly crash at all. You get a kind of silent death. The application is broken, but without a clear error. That is frustrating for users, and even more frustrating for developers, because the exact signal you need to debug the issue is missing.

By failing early, you make errors visible at the moment they are introduced.

And that makes debugging, testing, and maintaining software much easier. 🛠️

That is also why I am such a fan of clear validation, assertions, type safety, and guard clauses. Not to be "strict" for the sake of it, but to surface problems as early as possible.

Crash early is an important principle in defensive programming: make invalid situations explicit, instead of quietly dragging them through your application.

At Glaciavis, this is a principle all developers follow. It is a fixed part of our quality standard: errors should become visible as early as possible.

Because a bug you catch early is usually cheap to fix.

A bug that only shows up later is often far more expensive. 📉

So:

• Invalid input? Throw an error.
• Impossible state? Throw an error.
• A code path that should never be reached? Throw an error.

Do not hide it.

Do not guess.

Do not hope it will somehow work.

Crash early. ⚡

If you want high quality in your web applications and want to work with developers who take principles like this seriously, feel free to reach out.