A detailed discussion of these questions can be found in the "Appendix A" section on page 463.
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? ...