Fail Fast Principle

There are 3 keys ways a developer usually approaches error handling in code.

• Ignore
• Fail Safe
• Fail Fast

We have, at different point of writing code, used all three approaches. There are times when have good reasons to ignore a particular exception scenario, while at other times, we are opt for Fail Safe approach.

Fail Safe approach never hides the exception, but rather, delays it until it is safe to raise it. This is a reasonable approach, considering we are now swallowing an exception. But there is a huge problem with this approach. Most often than not, the Fail Safe approach makes the application to fail slowly, resulting in the system to continue working smoothly when the exception occurs and then fail later on. This, as a developer, inevitably leads you to spending hours debugging your code to trace a bug. What would have been a better approach ?

Fail Fast Principle

Fail Fast Principle that has its heart in Defensive Programming, encourage developers to fail fast and visibly when an exception occurs. The biggest benefit of this approach is a faster feedback loop. In early days of adhering to this principle, you might end with a lot frustrating moments as you might think your have build a fragile software, but remember, it is always better to fix the bugs upfront, than to have the customer face them. The Fast Fail Principle does exactly that for you and aids you in building a robust application.

That doesn’t mean that you should completely ignore the first two approaches. This is the guidelines I keep for myself.

• Use Ignore, only when having really specific reasons.
• Use Fast Safe, when it is a critical piece of code, and Failing Safe is a better approach
• Any other times, Use Fail Fast.