Flow of Control - Java - page 146

code, different test cases using a range of input and output values, and the logic behind the
algorithm itself. For example, consider the tax program in Display 3.1. If the wrong tax is
displayed, you might spend a lot of time trying to find an error in the code that calculates
the tax. However, the error might simply be that the input values were different from those
you were expecting, leading to an apparently incorrect program output. For example, in
German the decimal point and comma are reversed from the English usage. Thus, an
income of 25,000.50 becomes 25.000,50. A German programmer might make this type of
error if the code was written assuming input in the English format. Although this scenario
might seem like a stretch, consider the $125 million Mars Climate Orbiter launched by
NASA in 1998. In 1999 it was lost approaching the planet because one team used metric
units while another used English units to control the spacecraft's thrusters.
Determining the precise cause and location of a bug is one of the first steps in fixing the
error. Examine the input and output behavior for different test cases to try to localize the
error. A related technique is to trace variables to show what code the program is executing
and what values are contained in key variables. You might also focus on code that has
recently changed or code that has had errors before. Finally, you can also try removing code.
If you comment out blocks of code and the error still remains, then the culprit is in the
uncommented code. The process can be repeated until the location of the error can be pin-
pointed. The /* and */ notation is particularly useful to comment out large blocks of code.
After the error has been fixed, it is easy to remove the comments and reactivate the code.
The first mistakes you should look for are common errors that are easy to make.
These are described throughout this textbook in the Pitfall sections. Examples of com-
mon errors include off-by-one errors, comparing floating-point types with == , adding
extra semicolons that terminate a loop early, or using == to compare strings for equality.
Some novice programmers may become frustrated if they can't find the bug and
may resort to guessing. This technique involves changing the code without really
understanding the effect of the change but hoping that it will fix the error. Avoid such
slipshod hackery at all costs! Sometimes this method will work for the first few simple
programs that you write. However, it will almost certainly fail for larger programs and
will most likely introduce new errors to the program. Make sure that you understand
the logical impact a change to the code will make before committing the modification.
Finally, if allowed by your instructor, you could show the program to someone else.
A fresh set of eyes can sometimes quickly pinpoint an error that you have been miss-
ing. Taking a break and returning to the problem a few hours later or the next day can
also sometimes help in discovering an error.
EXAMPLE: Debugging an Input Validation Loop
Let's illustrate both good and bad debugging techniques with an example. Suppose our
program is presenting a menu where the user can select 'A' or 'B'. The purpose of the
following code is to validate user input from the keyboard and to make the user type a
choice again if something other than 'A' or 'B' is entered. To be more user-friendly, the
program should allow users to make their selections in either uppercase or lowercase.