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.
-
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,
-
It contains two bugs.
We'll track it down as follows.
-
Run our test-class's main method.
From inspecting the terminal-window output,
What method seems to contain the (first) bug?
-
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.
-
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