Question

I know the question is a bit simplistic, but I feel like I’m missing something big and obvious. I am following the tutorial for graphics handling in android from ( http://www.droidnova.com/playing-with-graphics-in-android-part-vi,209.html ). When I look at logcat, it tells me a line number where it thinks the null pointer exception came from) When I replace the numbers that are pulled from classes there with constants, the null pointer exception just moves somewhere else in the program.

Is there some way in the eclipse debugger to identify what specific pointer it views as the one that is null when it shouldn’t be? I get the null pointer exception, and that’s all it will say, that there’s an exception, but no information on what pointer is supposedly null.

Also, when I try to put in breakpoints for testing, while I can get the debugger to come up and stop at the breakpoint, logcat shows that a null pointer exception has still been thrown, even though the breakpoint should be hit before the part causing the exception comes up. Why are breakpoints being ignored?

Answer 1

Is there some way in the eclipse debugger to identify what specific pointer it views as the one that is null when it shouldn’t be?

The answer here is Yes and No. No: You cannot tell Eclipse to specify which pointer to check for null at. All you can do is watch the pointers themselves when you are broken in the class or function. Yes: All you have to do is split up your calls and you can find the object. For instance, the code in question seems to be:

_currentGraphic.getCoordinates().setX((int) event.getX() - _currentGraphic.getGraphic().getWidth() / 2);

You would split this up into (forgive the pseudo, but I don’t know which types you are working with):

Type _coords = _currentGraphic.getCoordinates();
Type _graphic = _currentGraphic.getGraphic();
Type _width = _graphic.getWidth();

_coords.setX((int) event.getX() - _width / 2);

Now, the line of code is broken up into one object per line, easily able to determine which is the offender.

Why are breakpoints being ignored?

This one is a bit more complicated. Your breakpoints may or may not be being ignored. In general, if you are getting to one breakpoint, it should be getting to all of them in order. However, I have noticed, in Eclipse, that sometimes breakpoints are ignored given certain circumstances. For some reason, the adb is not completely integrated with the Eclipse debugger. This means that if you change breakpoints in the middle of a currently running debug, it may or may not recognize them. Often it is enough to kill the app completely and redebug it.

Additionally, sometimes the adb and debugger do not synchronize correctly. There is a command that you can use (best at the beginning of your code) that helps that along quite nicely. If you insert the command Debug.waitForDebugger(), the synchronization will come into place allowing the earliest breakpoints (those in your first onCreate() and similar) to work correctly. The command does make you debugging much slower though. Using this at key points will also mitigate the blatant breakpoint ignoring discussed previously.

Now it is important to note that just because you think it is ignoring them, does not mean it is. Sometimes (especially with Android, right now), execution does not necessarily go through the paths the developer thinks that it does. For instance, one might set a breakpoint in the ViewClass(Context context) constructor, when it is actually created via XML with the ViewClass(Context context, AttributeSet attr) constructor. Heck, even a forgotten creation of an object can completely steer execution in the wrong way. This may be especially true if the object has static members or code that is run on class initialization (not object initialization). Without looking at your code, I cannot say which is happening, but hopefully this gives you the tools to find your answer.

Hope this helps,

FuzzicalLogic