Debugging and error processing are two of the most essential programming activities you will ever perform. There are three absolutes in life: death, taxes, and software bugs. Even in a relatively bug-free application, there is every reason to believe that a user will just mess things up royally. As a programmer, your job is to be the guardian of the user's data as managed by the application, and to keep it safe, even from the user's own negligence (or malfeasance) and also from your own source code.
I recently spoke with a developer from a large software company headquartered in Redmond, Washington; you might know the company. This developer told me that in any given application developed by this company, more than 50 percent of the code is dedicated to dealing with errors, bad data, system exceptions, and failures. Certainly, all this additional code slows down each application and adds a lot of overhead to what is already called "bloatware." But in an age of hackers and data entry mistakes, such error management is an absolute must.
Testingalthough not a topic covered in this bookgoes hand-in-hand with error management. Often, the report of an error will lead to a bout of testing, but it should really be the other way around: Testing should lead to the discovery of errors. When I first started work on this chapter, the daily news was reporting that NASA's Mars Global Surveyor, in orbit around the red planet, had captured images of the Beagle 2, a land-based research craft that crashed into the Martian surface in 2003. An assessment of the Beagle 2's failure pinpointed many areas of concern, with a major issue being inadequate testing:
Look at all those big words. Boy, the Europeans sure have a way with language. Perhaps a direct word-for-word translation into American English will make it clear what the commission was trying to convey: