Fail Fast principle

The fail fast principle stands for stopping the current operation as soon as any unexpected error occurs. Adhering to this principle generally results in a more stable solution. It might appear counter-intuitive at first. How is it so that failing at any error leads to stability? Isn’t it backward?

Indeed, when you start applying this practice, application crashes might seem overwhelming, especially if you have a working software whose developers didn’t stick to fail-fast before. But if you don’t give up, grit your teeth and fix all the code causing those failures, you will benefit from it greatly.

The trick here is that adhering to the fail fast principle, we improve the feedback loop. We quickly reveal all problems in our software making it easier to spot and fix them.

The opposite to fail-fast is fail-silently. How often did you encounter such code?

A common justification for wrapping everything in a generic try-catch block is that it makes a software feel more stable by not letting end users know about errors in it.

I bet you already know swallowing exceptions in a generic try-catch block generally is a bad practice. But why is it so, exactly?

The problem with such approach is that instead of revealing issues in the software, we mask them and thus extend the feedback loop. If something goes wrong with the application, it wouldn’t be obvious. The incorrect behavior is now hidden from the eyes of developers and end users and might stay unnoticed for a long time.

Moreover, the application’s persistence state may get corrupted if the code continues executing after an error took place.

The fix here is simple, we just need to add a "throw" statement to the catch block:

Check out this article to read more on how to work with exceptions.

So, what are the benefits the fail fast principle provides?

Failing silently is like burying your head in the sand. It doesn’t solve the underlying problem, only pretends the problem isn’t there.

In most cases, adhering to the fail fast principle means we should shut down the application (probably, with a polite apology) in case of any unexpected situation.

There are cases where we don’t have to kill the whole process, though. If the software is inherently stateless meaning that it doesn’t store any state in memory between the operations, it might be just fine to halt only the operation the error took place in and let the application continue working.

An example here is a web server. Requests it processes don’t leave any marks in the server’s memory so we don’t have to shut it down. Another good example would be a background job.

The principle is highly related to the design by contract concept.

The main purpose of code contracts is to give the ability to quickly determine issues in our code. Design-by-contract programming takes the fail fast principle to its extreme. It prescribes that software developers should define a formal set of rules the code itself and its clients should live by and crash the application if any violation of those rules takes place.

The great strictness makes it even possible to create static analyzers on top of the code contracts so that the problems can be revealed on the compilation stage, without ever launching the app.

There are plenty of examples of both adhering to the fail fast principle and violating it.

The work with configuration files is a good one. There are two ways of reading a config file. The fail fast approach would be fetching all the required values and validating them at once on the application start. If any of them is missing or invalid, the process should crash.

The opposite approach is to read the values ad hoc and fail (or even silently proceed) only when a setting is actually needed in the code.

The benefit of failing fast here is obvious: you don’t have to wait until some piece of code reveals the configuration is incorrect. If the application was successfully launched, you can be sure there wouldn’t be any issues with the config file later on.

Another example is nulls in such languages as C# and Java. Without a strict distinction between the types that allow for nulls and the types that don’t, it’s hard to see whether a particular instance had turned into null because a developer wanted it to or by a mistake.

Not only can null reference exceptions be tedious, they are often difficult to nail down. The reason is that they tend to occur not when the actual null assignment took place but rather when the instance was dereferenced. These two actions can be separated from each other by many lines of code, which makes it hard to find out what causes the problem.

The best solution here would be introducing non-nullable reference types as a language construct so that compiler wouldn’t allow such things as assigning null to an instance of a non-nullable type. Unfortunately, it is hardly feasible in the near future (at least for the C# language).

The second best solution for the problem would be throwing an exception in run-time as soon as the unexpected assignment takes place. I wrote about this approach here, check it out for more details.

Following the fail fast principle can become a great source of confidence your application works correctly. The main point here is that we shouldn’t let any unexpected situation escape our attention.

Let your software fail fast. That, in turn, would allow you to quickly fix any problem in it.