Lab 6: Debugging
When you hear the person sitting next to you in lab saying
a bug in my program”, you don't have to worry
about roaches infesting the computer. When we say
bugs we really mean logical errors in our
program. The first
bug, however, was a real live bug. Well, live at first. In 1947 at
University, a moth was found in one of the components of the Mark II
computer, and was causing problems.
And so, the word bug
expanded to include not only insects, but also logical errors in
programs. Evidently, the verb to debug became
one of the most
used verbs in the hi-tech world.
In this lab you will deal with debugging. You will practice
fixing some common types of bugs. The high point of the lab
is a tour of the debugger inside the Eclipse environment.
Reading Stack Traces
In the following exercises, you will compile and run a Java
will need to create a working directory and place two Java files into
you have problems with these activities, you should review the Windows
|In the command shell window,
change to your personal directory. (If necessary, create it.) What
commands did you issue? |
|Inside your personal
directory, create a subdirectory named debuglab.
What command did you issue? |
Next, download the files WordAnalyzer.java
them into the c:\yourname\debuglab directory. (As
always in this
tutorial, c:\yourname denotes your personal
directory. Be sure to
substitute c:\jqsmith or whatever your personal
Have a look at the WordAnalyzer class. A
constructed with a string—the word to be analyzed. Right now,
we only care about the first (buggy) method: firstRepeatedCharacter.
It returns the
first repeated character in a word, such as o in
The WordAnalyzerTester program simply
|Without actually running the
program, predict its output. Assume that the firstRepeatedCharacter
method works correctly. |
|Now run the program. What
output do you get? (Include the correct outputs and the error message.)
The program dies with
an exception and prints a stack
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: 4
a look at the stack trace. The first complaint is about the method
charAt of the java.lang.String
class. That's a library
class. It is extremely unlikely that a library class has a bug. It is
more common that one of its methods was called with bad parameters.
The next complaint is about line 26 of the firstRepeatedCharacter
the WordAnalyzer class.
|Exactly what source code do
you find in line 26 of WordAnalyzer?
|How did you locate line 26?
(If you are using Notepad to open the file, shame on you. Programmers'
editors have commands for displaying line numbers, and for moving the
cursor to a given line.) |
Now look at the call to charAt
in line 26.
word.charAt(i + 1)
|In theory, there are two
different exceptions that can be thrown in this call. What are
Of course, we know that word
not null in this case, so we know that
the error must be the index.
|(a) Explain the nature of the
bug, and how to fix it. (b) What output did you get after you fixed the
Have another look at the WordAnalyzer class.
Suppose that some knucklehead passed a null
pointer to the constructor:
WordAnalyzer wa = new WordAnalyzer(null);This
makes no sense, but if programmers always wrote code that makes sense,
you wouldn't be working through this lab.
|Try it out. Modify WordAnalyzerTester
and add a call test(null). Where is an exception
thrown? Why not in the constructor? |
It would be nice if we could get an exception
thrown in the constructor. The easiest way is to use an assertion.
An assertion is a condition that needs to be true for a program to
function properly. If it is not, then it is better to abort the program
with an error message. Here is how we would add an assertion to the WordAnalyzer
that assert is a keyword (similar to return
or throw), and not a method. Therefore, it is not
necessary to use () around the
Constructs an analyzer for a given word.
@param aWord the word to be analyzed (not null)
public WordAnalyzer(String aWord)
assert aWord != null;
word = aWord;
Assertions are disabled by default, for greater
takes a small amount of time to check each assertion, and in a
well-tested application, it is not necessary to test conditions that
aren't going to happen. For testing and debugging, we want to turn
If you launch a program from the command line, add the -ea
option right after the java command:
java -ea WordAnalyzerTesterNote the dash (-)
before the ea. It tells the virtual machine that ea
is an option and not a weird class name. If you like, you can also use
the long option name
java -enableassertions WordAnalyzerTesterIn
Eclipse, you have to work a bit harder. Select the Run
-> Run... menu item, then click on the Arguments
tab. In the VM arguments field, add -ea.
|Run the modified WordAnalyzerTester
(that is, the version to which you added the assert
statement) with assertions enabled. What is the stack trace now? Why is
that more helpful? |
Using assertions doesn't fix your bugs. It
simply gives a more
accurate report about the causes of errors. Still, assertions are an
easy and painless way for testing against bad things.
|Explain a situation in a
recent homework assignment where you could use an assertion for
something other than a null pointer check.
| ||Enabling assertions
during testing only and leaving them disabled after testing
is not a good default. It is is like
wearing a life vest while your boat is safely docked and flinging it
over the railing once you are at sea. It would be better if -ea
was the default for the virtual machine. |
Exceptions and assertions are useful to pinpoint drastic errors that
kill your program. But often, a sick program doesn't die. It limps
along and computes the wrong result. In order to find out what such a
program does, students often sprinkle their code with print
statements like this one:
System.out.println("Yoohoo! I got this far!");
statements are really dumb. You put them in, you take
them out, you put them back in, you comment them out, you
the comments, and when it all works you take them out for good. Until
the next bug appears. |
In this section, you will practice the use of logging
statements. Logging is easy. Instead of System.out.println,
simply use Logger.global.info. For example,
Logger.global.info("About to return from find. i=" + i);Logging
is better than System.out.println for two reasons:
Look at WordAnalyzerTester2.
It tests the firstMultipleCharacter method of the
WordAnalyzer class. That method also has a bug.
- There is no shame in logging.
You can leave the logging
statements in your code when you turn it in, demonstrating good
software engineering practice.
- It is
easy to turn all logging statements on or off.
|Which input to the firstMultipleCharacter
method does not yield the expected result? |
We will use logging to find the problem. Add
the following statements
at appropriate places of the find method:
Logger.global.info("Entering find. c=" + c + ",pos=" + pos);
Logger.global.info("About to return from find. i=" + i);
class is in the java.util.logging package.
|What is the code of
your find method? |
|What output do you get when
you run the WordAnalyzerTester2 class?
|Look at the logging messages.
Explain why the firstMultipleCharacter
method does not work. |
|You can fix the problem by
modifying either the firstMultipleCharacter
method or the find method. Fix the problem. What
fix did you make? |
|Run the program again. What
output do you get now? |
Of course, now you no longer need the logging
messages. To turn them
off, add this statement to the main method in WordAnalyzerTester2:
|Add that statement and run
the program again. What output do you get now? |
|Suppose you find another bug
and want to turn logging back on. How do you do that?
In a small program, using Logger.global.info
works fine. As
your programs grow larger, you can control your logging in
sophisticated ways. You can use different logging levels. Instead of info,
call methods severe for important messages or fine
for "fine-grained" messages. Then call the setLevel
method to set the level of the messages that you want to see in a
particular program run. You can also define your own logger objects in
addition to Logger.global. Look at the API
of the Logger class for more information.
Running a Debugger
Most development environments, including Eclipse and BlueJ,
have a debugger,
a tool that lets you execute a program in slow motion. You can observe
which statements are executed and you can peek inside
Debuggers can be complex, but fortunately there are only
three commands that you need to master:
In this lab, we will use the debugger that is a part of
Eclipse. If you
haven't worked with Eclipse before, be sure to first run through the compiler lab.
- Set breakpoint
- Single step
- Inspect variable
this section, you need the WordAnalyzerTester3
class that tests the buggy countRepeatedCharacters
method. That method counts the substrings consisting of repeated
character in a word. For example, the word mississippiiihas
a count of 4.
into the debuglab directory. Start Eclipse and
make a project consisting of the files in the debuglab
directory. Execute WordAnalyzerTester3.
What output do you get? |
method does the right thing for the first two test cases, but it
mysteriously fails on the string "aabbcdaaaabb".
It should report 4 repetitions, but it only reports 3.
Unfortunately, the debugger cannot "go back", so you can't
simply go to the point of failure and backtrack. Instead, you first
run your program at full speed until it comes close the point of
failure. Then you slow down and execute small steps, watching what
We know that the first two calls to the test
method in WordAnalyzerTester3 give the correct
results. It won't be too interesting to debug them. Instead, let's go
directly to the third call. We'll set a breakpoint
at that line, so that the debugger stops as soon as it reaches the line.
Move the cursor to the third call to test.
Then select Run -> Toggle Line Breakpoint
from the menu. You will see a small blue dot to the left of the line,
indicating the breakpoint.
right-click on the WordAnalyzerTester3
class in the package explorer window. Select the menu option Debug
As -> Java Application.
The debugger now
runs your program. When it hits the first breakpoint,
you get this dialog:
Simply click the Yes
button, and you'll
see a wholly different set of windows (i.e. the Debug perspective):
The green line shows where
the debugger has stopped.
the debugger as described. What output do you get in the console
window? Why do you get two lines of output and not three?
Now we want to step through the test method in
slow motion. Single-stepping is such a common command that Eclipse
gives you three ways of executing it:
- Select Run -> Step Into
from the menu
- Hit the F5 key
the "step into" icon in the Debug window
|Execute the "Step Into"
command. What happens? |
Now you are inside the test
method. The next call
WordAnalyzer wa = new WordAnalyzer(s);That call
is boring, and we do not want to step into the constructor. We'll use
the "Step Over" command instead.
|What are the three ways for
executing the Step Over command in Eclipse? |
|Execute the "Step Over"
command. What happens? |
Now you are at the line
int result = wa.countRepeatedCharacters();
we want to find out why we get the wrong repetition count for the third
test case. Should you execute "Step Into" or "Step Over" at
point? Why? |
Execute "Step Into" a couple of times. You
should get into the
int c = 0;
for (int i = 1; i < word.length() - 1; i++)Now
when you execute "Step Into" again, you will end up in the code for the
String class. That sometimes happens by accident.
In this case, there is no harm done since the length
method is so short. But it can be bothersome to be trapped in a long
library method (such as println). The remedy is
the "Step Return" command. It gets you out of the current method and
back to the caller.
|As described, execute "Step
Into" until you are inside the length method of
the String class. Then execute "Step Return".
What happens? |
Look inside the Variables window in the top right corner.
You can see the contents of
three variables, this
(the implicit parameter of the call wa.countRepeatedCharacters()),
c, and i.
The triangle next to this indicates
that you can expand the variable.
|Click on the triangle next
to this. What do you see? |
|Why are there no triangles
next to c and i?
Now keep executing the Step Over command. Watch what happens to the c
and i values. You'll see i
increase each time the loop is executed.
|The value of c
increases three times. What are the values for i
at each increase? |
|Look at the this.word
value. What is special about the three positions at which c
We will fix the bug in the next section. For
now, select the Run
-> Resume menu option. Your program runs again at full
speed, until it hits the next breakpoint or until it terminates.
|What happens when you execute
the "Resume" command? |
You now know how to use the debugger. You have
learned how to set
breakpoints, how to single-step, and how to view variables. The Eclipse
debugger has many advanced commands, but they are not needed for simple
Fixing the bug
The countRepeatedCharacters method looks for
character sequences of the form xyy,
that is, a character followed by the same character and preceded by a
different one. That is the start of a group. Note
that there are two conditions. The condition
if (word.charAt(i) == word.charAt(i + 1)) tests
for yy, that is, a
character that is followed by another one just like it. But if we have
a sequence yyyy, we only want it to count once.
That's why we want to make sure that the preceding character is
if (word.charAt(i - 1) != word.charAt(i))This
logic works almost perfectly: it finds three group starts: aabbcdaaaabb
|Why doesn't the method find
the start of the first (aa) group?
|Why can't you simply fix the
problem by letting i start at 0 in the for
|Go ahead and fix the bug. (a)
What is the code of your countRepeatedCharacters
method now? (b) Run the WordAnalyzerTester3
method again. What is the output now? |
||Is the program now free from bugs? That is not a question the
can answer. As the famous computer scientist Edsger Dijkstra pointed out: "Program testing can be used to show the presence of bugs, but never to show their absence!" As
you have seen in this lab, testing and debugging is a laborious
activity. In your computer science education, it pays to pay
special attention to the tools and techniques that ensure
correctness without testing. |