Programming | Java, JSP » Debugging lab

Debugging lab Introduction Finding the location of bugs or errors in software is an important skill. You deepened on it to get your software working and billions of dollars are spent annually on debugging software. “The debugging skill of the programmer is probably the biggest factor in the ability to debug a problem, but the difficulty of software debugging varies greatly with the programming language used and the available tools, such as debuggers. Debuggers are software tools which enable the programmer to monitor the execution of a program, stop it, re-start it, run it in slow motion, change values in memory and even, in some cases, go back in time.“ -- http://en.wikipediaorg/wiki/Debugging Regardless of the Integrated Development Environment (IDE) that you use, youll want to get familiar with the debugging tools it contains. In this lab youll have a chance to explore the debugging aids present in NetBeans. What follows is an adaptation of “Section 67 A Sample Debugging

Session” in the text. Setting the stage Copy the directory /users/ernie/220/javaSourceCode/ch06/debugger to your workspace directory. cp -r /users/ernie/220/javaSourceCode/ch06/debugger $HOME/workspace/ Start a NetBeans session and create a new project, Im using the name DebugSession, using the files in your directory workspace/debugger. Build the Main Project, and run it Enter the input hello yellow peach. Heres what youll see as the results: Enter a sentence ending in a period. hello yellow peach. Syllables in hello: 1 Syllables in yellow: 1 Syllables in peach.: 1 Obviously something is wrong here! (A first-time success is often a bit too much to ask.) Debugging Now well get started doing some debugging. When we debug well want to trace or look at the execution of the program and the values that are stored in the variables. Of course the program executes very quickly, so well have to stop the program at some point and examine the variables. A place where we stop the program is

called a breakpoint. The help files that accompany NetBeans define a breakpoint as follows. “A breakpoint is a flag in the source code that tells the debugger to stop execution of the program. When your program stops on a breakpoint, you can perform actions like examining the value of variables and single stepping through your program.” Examining he values of variables and being able to step through a program, either from one breakpoint to another or from one statement to another one Java statement at a time will be very valuable for us so we can understand what is happening to variables when the software is executing. First well take a look inside Word.java, the class Word, and take a look at the method that counts syllables. Open Word.java in a window and set a breakpoint on the line if (ch == e) end--; Find the line in the text, (it was line 44 the last time I tried it) right click and select Toggle Breakpoint Ctrl+F8 This sets a breakpoint at this statement. The next time

we run the program with debugging turned on, execution will pause at this point. When the software comes to this point and at other points in the debugging session well want to examine the values in the local variables. To view the local variables during a debugging session (as the author shows in Figure 6-8 in the text), Click on Window in the menu bar and select Debugging, and then Local Variables Alt+Shift+1. This opens a pane in the NetBeans window that lists local variables. If you ever want to see the set breakpoints, once again click on Window in the menu bar and select Debugging, but this time select Breakpoints Alt+Shift+5. One more thing, well need to start a debugging session. To do that click on Run in the menu bar and select Debug Main Project F5. This starts a debugging session To see how it works, click on DebugSession (debug) and enter the input you entered above, hello yellow peach. Remember the period at the end. Youll see a message at the bottom of the NetBeans

window saying Thread Main stopped executing at Word.java:44 That means the breakpoint we set worked! Now click on the pane labeled Local Variables. You should see a listing similar to Before going on, be sure you know what youre reading. What does count represent? What does end represent? What does ch represent? What is this? When you know what youre reading, expand the value of this. Youll see the values of the instance variables for the object. Pretty neat, huh? Looking at these you see theres something wrong, because we expect text to have the value hello but it only contains hell. So it looks like syllableCounter doesnt have the correct information to do its work correctly. If we were familiar with the software wed know that the text of a word is determined in the constructor. Naturally, if we designed the class wed know that In any case, we might naturally start checking the constructor, because thats where the instances variables are likely to get their initial values.

Unfortunately, a debugger cannot go back in time. Thus, you must stop the debugger, set a breakpoint in the Word constructor, and restart the debugger. To stop the debugger, Click on Run in the menu bar and select Finish Debugger Session Set a break point in the constructor, say at line 19, text = s.substring(i, j); Debug the main project (F5) and supply input again. The debugger will stop at the breakpoint Look at the values of the local variables, i and j. The constructor sets two variables i and j, skipping past any nonletters at the beginning and the end of the input string. At this point, inspecting i and j shows that i is 0 and j is 4. That makes sensethere were no punctuation marks to skip. So why is text being set to ”hell”? Recall that the substring method counts positions up to, but not including, the second parameter. Thus, the correct call should be text = s.substring(i, j + 1); This is a very typical off-by-one error. Fix the error, and rebuild the program Run the

program (without a debug session) using the original input hello yellow peach. Youll see Enter a sentence ending in a period. hello yellow peach. Syllables in hello: 1 Syllables in yellow: 1 Syllables in peach.: 1 Dang! Same results! Erase all breakpoints and set a breakpoint in the countSyllables method. Start the debugger and supply the input hello. When the debugger stops at the breakpoint, start single stepping through the lines of the method. To single step through a program, once youve hit a breakpoint, press F7. That takes the execution through one Java statement. Here is the code of the loop that counts the syllables: boolean insideVowelGroup = false; for (int i = 0; i <= end; i++) { ch = Character.toLowerCase(textcharAt(i)); if ("aeiouy".indexOf(ch) >= 0) { // ch is a vowel if (!insideVowelGroup) { // Start of new vowel group count++; insideVowelGroup = true; } } } In the first iteration through the loop, the debugger skips the if statement. That makes

sense, because the first letter, ’h’, isnt a vowel. In the second iteration, the debugger enters the if statement, as it should, because the second letter, ’e’, is a vowel. The insideVowelGroup variable is set to true, and the vowel counter is incremented. In the third iteration, the if statement is again skipped, because the letter ’l’ is not a vowel. But in the fifth iteration, something weird happens The letter ’o’ is a vowel, and the if statement is entered. But the second if statement is skipped, and count is not incremented again Why? The Secret Revealed! The insideVowelGroup variable is still true, even though the first vowel group was finished when the consonant ’l’ was encountered. Reading a consonant should set insideVowelGroup back to false This is a more subtle logic error, but not an uncommon one when designing a loop that keeps track of the processing state. To fix it, stop the debugger and add the following clause: if

("aeiouy".indexOf(ch) >= 0) { . } else insideVowelGroup = false; Now recompile and run the test once again. The output is: Syllables in hello: 2 Syllables in yellow: 2 Syllables in peach.: 1 Is the program now free from bugs? That is not a question the debugger can answer. Remember: Testing can show only the presence of bugs, not their absence