Java Reference
In-Depth Information
examine the source 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 pinpointed. 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 common
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 cannot 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 missing.
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 upper- or lowercase.
VideoNote
Debugging
Walkthrough
