Chapter 8. Defensive Programming

cc2e.com/0861

Contents

• Protecting Your Program from Invalid Inputs page 188

• Assertions page 189

• Error-Handling Techniques page 194

• Exceptions page 198

• Barricade Your Program to Contain the Damage Caused by Errors page 203

• Debugging Aids page 205

• Determining How Much Defensive Programming to Leave in Production Code page 209

• Being Defensive About Defensive Programming page 210

Related Topics

• Information hiding: "Hide Secrets (Information Hiding)" in Section 5.3

• Design for change: "Identify Areas Likely to Change" in Section 5.3

• Software architecture: Section 3.5

• Design in Construction: Chapter 5

• Debugging: Chapter 23

Defensive programming doesn't mean being defensive about your programming "It does so work!" The idea is based on defensive driving. In defensive driving, you adopt the mind-set that you're never sure what the other drivers are going to do. That way, you make sure that if they do something dangerous you won't be hurt. You take responsibility for protecting yourself even when it might be the other driver's fault. In defensive programming, the main idea is that if a routine is passed bad data, it won't be hurt, even if the bad data is another routine's fault. More generally, it's the recognition that programs will have problems and modifications, and that a smart programmer will develop code accordingly.

This chapter describes how to protect yourself from the cold, cruel world of invalid data, events that can "never" happen, and other programmers' mistakes. If you're an experienced programmer, you might skip the next section on handling input data and begin with Section 8.2, which reviews the use of assertions.