using the debugger

[gerrymcc]

Hi,
I've got a loop which is going through an array, and I'm getting an
array index out of bounds exception. Usually to find this sort of
error I'd use System.out.println() or look at the code until the penny
drops, but I think it must be quicker to use the debugger. I want to
see the local variables in the loop, so I recompiled the class with
the loop, and the main class. The debugger says to recompile with -g
so I did:
javac -g TheMainClass.java, and javac -g TheLoopClass.java.
Then when I run the program and the debugger stops at the exception,
I type locals and the debugger still says recompile with -g.
Does that mean I need to recompile every class the program is using?
Also, is there any tutorial or instructions for using the debugger?
Documentation for any standard debugger would probably explain some of
the general priciples I need to know.
Thanks for any help,
Gerard

 

[Harald Hein]

Usually to find this sort
of error I'd use System.out.println() or look at the code until
the penny drops, but I think it must be quicker to use the
debugger.

Congratulations! A lot of programmers can't even be bothered to touch a
debugger. See the recent discussion about logging vs. debugging where
many pulled a lot of fake arguments why logging is sooooooo great.

Knowing how to efficiently use a debugger is a huge advantage and can
can make you the king of the town.

I want to see the local variables in the loop, so I
recompiled the class with the loop, and the main class. The
debugger says to recompile with -g so I did:
javac -g TheMainClass.java, and javac -g TheLoopClass.java.
Then when I run the program and the debugger stops at the
exception, I type locals and the debugger still says recompile
with -g. Does that mean I need to recompile every class the
program is using?

It is difficult to say, because it depends on the inner working of the
debugger. I never studied the java debugger in detail, but you should
at least compile everything which you want to trace, set a breakpoint
on, or just display with -g. And because you dont know in advance what
you want to see (you never know where debugging leads you to), it is
best to compile everything with -g.

If you have the resources (if your program doesn't get to large or to
slow with -g) it is a good habbit to always compile everything with -g
while you develop the program. Add the flag to your ant scripts or
makefiles. Then you don't need any extra steps when you decide it is
time for a debugger. Which is another big advantage over the
System.out.println shotgun approach. If you compile everything with -g
you can start the debugger whenever you want. If you use println you
always have to add more to your code and recompile.

Also, is there any tutorial or instructions for
using the debugger?

The only one I am aware of is the one in Sun's SDK dokumentation. It
lists the commands. You maybe want to get a better debugger. All the
free IDEs have better ones than Sun's command line tool. It can't hurt
to know Sun's tool in case of emergency, but for day to day work it is
not the best to use.