BackgroundIn the period 1960-1998 it was common for developers to implement strict code that required highly specific inputs. At the first sign something was wrong, such code threw errors. For example, if an XML parser encountered a character it didn't understand it would typically throw an exception as opposed to simply skipping the character and continuing. This approach made sense in a world of corporate software where data corruption was viewed as far worse than an runtime error.Around 1998, when the commercialization of the internet began to heat up, a culture shift occurred whereby programmers who took a more practical approach to parameters began to dominate. This occurred due to the demands of the time such as serving novice users on the web, processing unstructured data and dealing with natural language. For example, web browsers that blow up on the slightest html standards non-compliance wouldn't be able to display most pages in the real world. This flexible approach to taking parameters and figuring them out as opposed to throwing errors when something isn't to specifications eventually became known as defensive programming.As with most programming principles that are seemingly logical and intuitive, defensive programming is often taken too far whereby code refuses to fail. This can be dangerous in terms of incorrect interpretations of parameters. It also tends to lead to methods that don't complete their work but are too cowardly to throw an exception.
|Overview: Defensive Programming
Anticipating things that will likely go wrong and coding to handle such scenarios as opposed to easily throwing exceptions.
Writing code that can handle real world scenarios.
Obscure, difficult to test code for scenarios that may not happen. Code that fails to complete its work but acts as if everything is fine leading to complex problems that are difficult to troubleshoot in production.Incorrect interpretations of parameters that lead to business failures or corrupt data.