This article promotes the fail-fast approach, something I very much dislike (against popular opinion it seems).
I'm very much in favor of the opposite approach, defensive coding. Often when I read opinion pieces about how bad defensive coding is, they almost always seem to forget that defensive coding without proper logging, error-handling and monitoring is NOT defensive coding.
It is extremely dangerous to just detect error conditions without any feedback: you have no idea what is going on in your system!
IMHO properly applied defensive coding, works as follows:
* Detect inconsistent situations (e.g. in a method, expected an object as input argument, but got a null)
* Log this as an error and provides feedback to the caller of the method that the operation failed (e.g. through an error callback).
* The caller can then do anything to recover, (e.g. reset a state, or move to some sort of error state, close a file or connection, etc.).
* The caller should then also provide feedback to its caller, etc. etc.
This programming methodology gives the following advantages:
* You are made to think about the different problems that can occur and how you should recover them (or not)
* Highly semantic feedback about what is going wrong when an issue occurs; this makes it very easy to pinpoint issues and fix them
* Server application keeps on running to handle other requests, or can be gracefully shut down.
* Client side application UIs don’t break, user is kept in the loop about what is happening
Of course you will need to keep a safety net to catch uncaught exceptions, properly logging and monitoring them (and restart your application if relevant)
The fail-fast approach, as I have seen it applied, doesn’t do any checking or mitigation, with the effect that:
- you are thrown out of you normal execution path, losing a lot of context to do any mitigation (close a file, close a connection, tell a caller something went wrong)
- you only get a stack trace from which it can be hard to figure out what went wrong
- there can be big impact on user experience : UIs can stop working, servers that stop responding (for all users).
I have very good experiences with using the defensive coding paradigm, but it takes more work to do it right; for many, especially in the
communities that use dynamic typing, such as the JS community, this seems to be a too big a hurdle to take. This is unfortunate
because it IMO it could greatly improve software quality.
Any feedback is welcome!
(Edit: formatting to improve readability)
(Edit: clarified defensive coding as an opposite approach to fail-fast)
FWIW, I wouldn't suggest the term "defensive coding" as the opposite to "fail fast". It's very similar to the established term "defensive programming", which IMHO is more about designing systems to make fewer assumptions. How you then handle a situation where you do detect that some expectation has not been met, including the fail-fast strategy, seems like a related but separate issue.
Terminology aside, though, I agree with much of what you say. The idea that it's generally acceptable for buggy code to just crash out seems to be making an unwelcome return recently, often among the same kinds of developers who don't like big design up front or formal software architecture because they want everything to be done incrementally and organically, and in the case of web apps specifically, often among developers who also consider code that runs for a year or two to be long-lived anyway.
With defensive coding I indeed meant defensive programming. You always want to fail fast (faster also means that you can fix more bugs), but this is often interpreted as "fail hard": no prevention or mitigation what so ever. In this sense I meant it is the opposite of defensive programming.
What I notice is that developers who also have a background in statically typed (system) languages, are much more disciplined when it comes to defensive programming and logging/error handling. (I'm afraid this also correlates with age).
BTW, I like your description, "designing systems to make fewer assumptions", for defensive programming!
I'm very much in favor of the opposite approach, defensive coding. Often when I read opinion pieces about how bad defensive coding is, they almost always seem to forget that defensive coding without proper logging, error-handling and monitoring is NOT defensive coding. It is extremely dangerous to just detect error conditions without any feedback: you have no idea what is going on in your system!
IMHO properly applied defensive coding, works as follows:
* Detect inconsistent situations (e.g. in a method, expected an object as input argument, but got a null)
* Log this as an error and provides feedback to the caller of the method that the operation failed (e.g. through an error callback).
* The caller can then do anything to recover, (e.g. reset a state, or move to some sort of error state, close a file or connection, etc.).
* The caller should then also provide feedback to its caller, etc. etc.
This programming methodology gives the following advantages:
* You are made to think about the different problems that can occur and how you should recover them (or not)
* Highly semantic feedback about what is going wrong when an issue occurs; this makes it very easy to pinpoint issues and fix them
* Server application keeps on running to handle other requests, or can be gracefully shut down.
* Client side application UIs don’t break, user is kept in the loop about what is happening
Of course you will need to keep a safety net to catch uncaught exceptions, properly logging and monitoring them (and restart your application if relevant)
The fail-fast approach, as I have seen it applied, doesn’t do any checking or mitigation, with the effect that:
- you are thrown out of you normal execution path, losing a lot of context to do any mitigation (close a file, close a connection, tell a caller something went wrong)
- you only get a stack trace from which it can be hard to figure out what went wrong
- there can be big impact on user experience : UIs can stop working, servers that stop responding (for all users).
I have very good experiences with using the defensive coding paradigm, but it takes more work to do it right; for many, especially in the communities that use dynamic typing, such as the JS community, this seems to be a too big a hurdle to take. This is unfortunate because it IMO it could greatly improve software quality.
Any feedback is welcome!
(Edit: formatting to improve readability) (Edit: clarified defensive coding as an opposite approach to fail-fast)