Admittedly, my question is basically the same as this one, but it seems to have been left unanswered:
NullPointerException in handleStopActivity -- No reference to my code in stack trace
Downloaded Eclipse Helios, Android Developer Tools Plugin, and the JDK all within the last week. I was messing around with an app on my device, ran it in Debug mode, and it unexpectedly terminated. I realized I had caused a NullPointerException and the problem itself was not an issue for very long.
What is an issue, however, is that the debugger seems unable to identify where in my code the exception was thrown. The stack trace does not reference my code.
Indeed, if I put the following in the OnCreate() method, I get the same problem
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
//lI("onCreate()"); //A silly logging thing I messed around with
Integer iDareYou = null;
iDareYou.byteValue();
Much to its credit, Eclipse certainly warns me that the code is likely to blow up in my face. But when I actually run this on my device, the stack trace returned is the following:
Thread [<1> main] (Suspended (exception RuntimeException))
ActivityThread.performLaunchActivity(ActivityThread$ActivityRecord, Intent) line: 2787
ActivityThread.handleLaunchActivity(ActivityThread$ActivityRecord, Intent) line: 2803
ActivityThread.access$2300(ActivityThread, ActivityThread$ActivityRecord, Intent) line: 135
ActivityThread$H.handleMessage(Message) line: 2136
ActivityThread$H(Handler).dispatchMessage(Message) line: 99
Looper.loop() line: 144
ActivityThread.main(String[]) line: 4937
Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method]
Method.invoke(Object, Object...) line: 521
ZygoteInit$MethodAndArgsCaller.run() line: 868
ZygoteInit.main(String[]) line: 626
NativeStart.main(String[]) line: not available [native method]
I searched around for some answers and unfortunately all I could come up with were questions of the 'Why is my Android app causing a NullPointerException'? variety.
I'm hoping to find out what I should be doing differently in order to be able to find the point in my code where I caused the exception.... because I'm sure this ability would come in handy at some point in the future!
Going to edit this to add some information. As the first comment below mentions, the state in which the debugger suspends the thread is not the 'final' state of the application. Pressing 'resume' a couple times moves the process along to the point where the process actually terminates, although unfortunately no helpful stack trace is displayed in the Eclipse/ADT Debug window. However, at this point the stack trace I pasted above Followed By the first 3 unique lines of the stack trace of the NPE in my code is output to LogCat. I had previously looked to see if LogCat had anything I could use, but most likely it was before I had pressed 'resume' in the debugger to move the process to this state. Unfortunately though, doing it this way never displays a stack trace of the NPE in my code in the actual debugger.
But the news isnt all bad - from the information in the 'Variables' window on the right, I can see that there is an NPE in the thread's current scope, so that would at least give me a clue that an NPE is going on (and of course there is LogCat).
So based on a suggestion in a different topic, the best work around I've found is to add a "Caught and Uncaught" breakpoint for NullPointerException. When I do this and relaunch, the debugger displays the stack trace of the NPE in my code, and moves the edit window straight to the line where I caused the NPE.
At the moment I believe this is because the NPE is being caught (and presumably, thrown again) by the Android framework. It appears the original dilemma was caused by the fact that the Eclipse/ADT/DalvikVM Debug Stack Trace window does not include the 'caused by' information (as far as I can tell) that is displayed in the stack trace "later" appearing in LogCat. I will investigate further as to whether this can be remedied :)
I appreciate Bert F's suggestion, as I was not fully aware that the thread was not yet in its 'final' state. While it is true that the stack trace is [later] displayed in LogCat, I did not 'miss' it in LogCat because it was not [yet] there, what I did miss was hitting 'resume' which would have caused the stack trace to be output in LogCat.
Even though I originally got the debugger to stop at the line in my code using a breakpoint, there is a case for the fact that I could have ultimately obtained the stack trace in LogCat after resuming the thread, which would have effectively solved the problem. The only other thing I could really ask for would be to have the debugger stop at the line in my code causing the exception, instead of it being caught and later re-thrown by the Android framework. But I believe that would be a different question :) And Eclipse, being useful as it is, will send me there if I click on the appropriate line in the stack trace displayed in the LogCat window.
