In the previous lesson you saw how to test a class.
How to debug a class
Finding where you have a bug in your classes can sometimes be a time-consuming process. To help you, NetBeans incorporates a debugging tool that lets you set one or more breakpoints at any point in your code. A breakpoint is a statement at which code execution will pause, allowing you to step through the subsequent statements one at a time, viewing the state of the variables as you go.
You will now introduce a bug into the validate() method of Email.java. In the section that ensures that there is exactly one @ character, change the following line from:
if (countAts != 1) {
To this:
if (countAts != 2) {
This would cause an error to be flagged when testing. Put the following code in the main() method of Experiments.java (in the VirtualZoo project):
public static void main(String[] args) {
Email e = new Email("fred@example@.com");
System.out.println(e);
}
The above email contains two @ characters, so run Experiments.java to ensure that no exception is being thrown.
Now, in the Email.java source file locate the first line of code inside the validate() method, and click inside the grey numbered margin at the left of the statement. The statement should turn red, indicating that you have set a breakpoint at that line:
On the Experiments.java node, right-click and select Debug File. This will tell NetBeans to run the program only as far as the first breakpoint it finds and then pause. The code will be displayed in the main window with the line which has its breakpoint set coloured green. In the Output window you can see the state of the object:
The this entry under the Name column refers to the current object. Click the small plus icon next to it to view the instance variables. You should see email appear, of type String and with a value of "".
Above the source code you will see a bank of icons:
Click the fourth of these (whose hover help is Step Over) and the statement will be executed, causing the green line to move and stop at the next statement. It jumps over the line which throws the exception since the condition was not met, hence it should now be on the line that declares countAts:
Step over to the next line and verify that the value of countAts is zero. Keep stepping over to loop through the check of each character until the green line reaches the following statement:
if (countAts != 2) {
At this point, the Output window should show that countAts has value 2, and that the comparison should be against 1. As you now know the problem, you can stop execution completely by clicking the first icon in Figure 10.8 (whose hover help is Finish Debugger Session).
In Email.java, change the comparison statement back to compare not equal to 1 rather than 2. Now click in the grey numbered margin next to the red line to turn off the breakpoint. Each time you click the margin the statement will toggle between being set and unset. You should now be able to run Experiments.java with a correct outcome, i.e., an exception is correctly being thrown.
If while you are single stepping a debugging session the next statement is a method call, you have a choice of either stepping over it or inside of it. Stepping over is useful if you are sure the method itself is not the problem, because its code is still executed but you don't have to waste time stepping through each line. However, if you are unsure where the fault lies then using the Step Into icon takes you into the called method, even if it is in a completely different class that has no breakpoints of its own. This is very useful for tracing the cause of an error.
In the next series of lessons you will learn about collections and maps.
Comments