Get Thinking

A detailed discussion of these questions can be found in the "Appendix A" section on page 463.

Mull It Over

  1. Can you have too much defensive programming?

  2. Should you add an assertion to your code for every bug you find and fix?

  3. Should assertions conditionally compile away to nothing in production builds? If not, which assertions should remain in release builds?

  4. Are exceptions a better form of defensive barrier than C-style assertions?

  5. Should the defensive checking of pre- and postconditions be put inside each function, or around each important function call?

  6. Are constraints a perfect defensive tool? What are their drawbacks?

  7. Can you avoid defensive programming?

    1. If you designed a better language, would defensive programming still be necessary? ...

Get Code Craft now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.