ITEC 120 2008fall aaray, ejderrick, ibarland, jmdymacek

home—info—labs—hws—exams
textbook—java.lang docs—java.util docs—archive

lab10b
debugging

Today we will use the debugger tool built into BlueJ.

1. Make a new project with the following two classes which are a (buggy) solution to last week's 'Pig Latin' lab: VowelExpert.java, TestVowelExpert.java,
2. It contains two bugs. We'll track it down as follows.
3. Run our test-class's main method. From inspecting the terminal-window output, What method seems to contain the (first) bug?
4. Now, open VowelExpert and click on the line-number, for a line inside the faulty method, firstA. BlueJ will put a little stop-sign (a “breakpoint”) by that line.
5. Then you can run your program/tests as normal, but when BlueJ reaches a breakpoint, it pauses executing and puts up a debugger-window. This window contains three important panels:
   • Local Variables. This window shows each currently-defined variable. Perhaps the bug is here -- perhaps one of our local variables does not have the value we thought it had!
   • Instance Variables. These are the fields of the object whose method is currently active. Perhaps the bug is here -- perhaps one of our fields does not have the value we thought it had!
   • Call Sequence (or “Call Stack”): This lists the current method being called, followed by where it was called from (and where that method was called from, etc..) You can imagine reading this bottom-to-top, to excavate a chronological history of what's happening.
     You can click on various methods back in the call sequence, and the other windows (local variables, instance variables) will change accordingly.
   In addition to those important panels, there are three important buttons available:
   • Step: run the next line of the program (currently highlighted in yellow), and then pause again.
   • Step Into: run the next line of the program, but if this line contains a method-call, we'll step down "into" that method. Watch how the call-stack increases when this happens, and the local variables re-sets!
   • Continue: resume running the program as normal, but it will halt again if it re-reaches this breakpoint or another one.
     This is helpful when a bug happens on (say) the 7th call to a function -- you can continue through the first 6 times, and then pay close attention on the 7th time.

After you fix both bugs, here's a method to paste into class VowelExpert. Step through it, to see how it works:

    /** A mystery method.  Step through this with a debugger.
     * (It doesn't actually compute anything meaningful, though.)
     */ 
    public String mystery() {
        final int N = 8;
        final String spell = "Supercalifragilisticexpialidocious";
        
        String nonsenseSoFar = "";
        for (int i=0; i+N <= spell.length(); i=i+2) {
            System.out.print( i + ": " );
            String smidgen = spell.substring(i,i+N);
            String edjumacated = toPigLatin( smidgen );
            nonsenseSoFar += edjumacated.substring(2,3);
            System.out.println( edjumacated );
            }
        return nonsenseSoFar;
        }

Upshot: Good programming tip: Writing small methods and making test cases is the best way to isolate bugs easily (and avoid them altogether). If you need to resort to the debugger you can, but it's no replacement for writing several small helper methods, testing it, and then calling it to help with a larger task!

Note that many other IDEs have debuggers, which probably include more features than BlueJ's. For example, Eclipse's debugger lets you set "watch points": “keep running until my variable x changes”. From the command-line, you can run the debugger jdb.

home—info—labs—hws—exams
textbook—java.lang docs—java.util docs—archive

©2008, Ian Barland, Radford University Last modified 2008.Nov.11 (Tue)

Please mail any suggestions (incl. typos, broken links) to iba�rlandrad�ford.edu