Java Reference
In-Depth Information
Exercise 7.30
Open the
calculator-engine-print
project and complete the addition of print
statements to each method and the constructor.
Exercise 7.31
Create a
CalcEngineTester
in the project and run the
testAll
method.
Does the output that results help you identify where the problem lies?
Exercise 7.32
Do you feel that the amount of output produced by the fully annotated
CalcEngine
class is too little, too much, or about right? If you feel that it is too little or too
much, either add further print statements or remove some until you feel that you have the right
level of detail.
Exercise 7.33
What are the respective advantages and disadvantages of using manual
walkthroughs or print statements for debugging? Discuss.
7.8.1
Turning debugging information on or off
If a class is still under development when print statements are added, we often do not want to see
the output every time the class is used. It is best if we can find a way to turn the printing on or off as
required. The most common way to achieve this is to add an extra
boolean
debugging field to the
class and then make printing dependent upon the value of the field. Code 7.7 illustrates this idea.
Code 7.7
Controlling whether
debugging information
is printed or not
/**
* A number button was pressed.
* @param number The number that was pressed.
*/
public
void
numberPressed(
int
number)
{
if
(debugging) {
System.out.println(
"numberPressed called with: "
+
number);
}
displayValue = displayValue * 10 + number;
if
(debugging) {
reportState();
}
}
A more economical variation on this theme is to replace the direct calls to print statements with
calls to a specialized printing method added to the class.
2
The printing method would print only
if the
debugging
field is
true
. Therefore, calls to the printing method would not need to be
2
In fact, we could move this method to a specialized debugging class, but we shall keep things simple in
this discussion.
Search WWH ::
Custom Search