CHAPTER 11 ■ DEBUGGING WITH ECLIPSE
Stepping Into
When you step into a line, you advance to the first of whatever methods may be in the line. Consider the
second line in the draw method:
g.setColor(drawColor);
When you step into that line, you step to the top of the setColor method in the Graphics class.
That's probably not very useful; you only want to use this command to step into your own code.
For some lines, stepping into is the same as stepping over, because nothing in the line changes the
execution point. For example, stepping into the first line of the draw method has the same effect as
stepping over it, because that line just assigns one value to another value.
Stepping Over
When you step over a line, you let the debugger run through whatever methods may be called by that
line. That includes any classes and methods that may be called by those methods, and so on. Sometimes,
that amounts to very little code; other times, it's a large chunk of a Java library.
Stepping over lines is a good way to find the place in your program where you have a problem. Step
over until the problem behavior presents itself. Then you know which line is bad. From that point, you
can step into the methods under that line, and then step over the lines in those methods until you hit the
problem spot again. Thus, by swapping back and forth between stepping over and stepping into code,
you can narrow down and finally locate the failure in your code.
Stepping to Return
Step Return lets the program run until the current method returns. Step Return is really just a
convenience feature so that you don't have to step through all the lines in a method. If you step into a
method and realize that it can't possibly be the source of your problem, Step Return offers a handy way
to move along.
Removing a Line Breakpoint
You may have noticed that the command for creating a breakpoint is TToggle Breakpoint. Toggling an
existing breakpoint removes it.
Disabling a Line Breakpoint
Sometimes, it's handy to leave a breakpoint in place but not use it for a while. For example, you might
disable a breakpoint while you track down some other bug that you have to fix sbefore you can deal with
the one you originally started to fix. You'll sometimes find that a bug is really a nested set of bugs, and
you have to fix one before you can fix another. The good news is that identifying one bug often gives you
insight into the larger problem, and fixing the remaining issues then becomes largely mechanical. There
are times, though, when you hit a series of hard-to-solve problems, and then you'll be happy to have a
good debugger. To disable a breakpoint:
- Right-click the breakpoint you want to disable.
- Choose Disable Breakpoint.