Bugs, Errors, Mistakes, and Code Rot

It has been said that if cities were built like software is built, the first woodpecker to come along would level civilization. The fact is that all too many commercial programs, from some of the biggest vendors in the business, have bugs. Serious bugs.

Although this is true, that does not make it okay; and writing robust, bug-free programs should be the number-one priority of anyone serious about programming. I would argue that the single biggest problem in the software industry is buggy, unstable code. Certainly the biggest expense in many major programming efforts is testing, finding, and fixing bugs.

There are a number of discrete kinds of bugs that can trouble a program. The first is poor logic: The program does just what you asked, but you haven't thought through the algorithms properly. The second is syntactic: You used the wrong idiom, function, or structure. These two are the most common, and they are the ones most programmers are on the lookout for. Far harder to find are subtle bugs that pop up only when the user does something unexpected. These little logic bombs can lurk quietly and undisturbed, like a land mine after the war is over. You think everything is okay and then suddenly—BAM!—someone steps in the wrong place and your program blows up.

Research and real-world experience have shown beyond a doubt that the later in the development process you find a problem, the more it costs to fix it. The least expensive problems or bugs to fix are the ones you manage to avoid creating. The next cheapest are those the compiler spots. The C++ standards force compilers to put a lot of energy into making more and more bugs show up at compile time.

Bugs that get compiled but are caught at the first test—those that crash every time—are less expensive to find and fix than those that are flaky and only crash once in a while.

A bigger problem than logic or syntactic bugs is unnecessary fragility: Your program works just fine if the user enters a number when you ask for one, but it crashes if the user enters letters. Other programs crash if they run out of memory, or if the floppy disk is left out of the drive, or if the modem drops the line.

To combat this kind of fragility, programmers strive to make their programs bulletproof. A bulletproof program is one that can handle anything that comes up at runtime, from bizarre user input to running out of memory.

It is important to distinguish among bugs. There are those that arise because the programmer made a mistake in syntax. There are also logic errors that arise because the programmer misunderstood the problem or how to solve it. Finally there are exceptions that arise because of unusual but predictable problems such as running out of resources (memory or disk space).

Handling the Unexpected

Programmers use powerful compilers and sprinkle their code with asserts to catch programming errors. They use design reviews and exhaustive testing to find logic errors.

Exceptions are different, however. You can't eliminate exceptional circumstances; you can only prepare for them. Your users will run out of memory from time to time, and the only question is what you will do. Your choices are these:

• Crash the program.

• Inform the user and exit gracefully.

• Inform the user and allow the user to try to recover and continue.

• Take corrective action and continue without disturbing the user.

Although it is not necessary or even desirable for every program you write to automatically and silently recover from all exceptional circumstances, it is clear that you must do better than crashing.

C++ exception handling provides a type-safe, integrated method for coping with the predictable but unusual conditions that arise while running a program.