Many people argue against defensive programming, but this is often because of the types of methods they have seen espoused by some as defensive programming. Defensive programming should not be viewed as a way to avoid test driven development or as a way to simply compensate for failures and move on. […] What are these methods, if not ways to anticipate that your program may fail, and either prevent those, or else ways in which to handle those failures appropriately?
They go on to talk about the ideas of "failing fast" when errors happen in your application with an extra suggestion added on – "fail loud" too. The tutorial then looks at four different places where more defensive programming techniques can be applied (and how):
- Input validation
- Preventing Accidental Assignment in Comparisons
- Dealing with Try/Catch and Exceptions
They end with a recommendation that, while you should fail fast and loud when issues come up, be sure it’s not to the determent of the overall user experience or sharing messages with users that may just confuse them.