Get Thinking
A detailed discussion of these questions can be found in the "Appendix A" section on page 463.
Mull It Over
Can you have too much defensive programming?
Should you add an assertion to your code for every bug you find and fix?
Should assertions conditionally compile away to nothing in production builds? If not, which assertions should remain in release builds?
Are exceptions a better form of defensive barrier than C-style assertions?
Should the defensive checking of pre- and postconditions be put inside each function, or around each important function call?
Are constraints a perfect defensive tool? What are their drawbacks?
Can you avoid defensive programming?
If you designed a better language, would defensive programming still be necessary? ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access