2

I'm trying to develop an application for Android, but I'm having difficulties tracing the source and cause of each exception I get in the process. My code runs in an Activity, and if a line of mine causes an exception, then rather than stopping on that line and highlighting it, it throws me into the ActivityThread class's code, which apparently I don't have, so I just get a "Source not found" screen.

Trying to find the troublesome line like this is very frustrating, so I'm trying to find a way to prevent Android's code from catching every exception during development. My searches online have yielded no information as to how I go about doing this, so I decided to ask here.

Here is the stack trace before the exception is thrown in my code:

Thread [<1> main] (Suspended (breakpoint at line 72 in GameView))
GameView.showMenu() line: 72
GameView.init() line: 59
GameView.(Context, AttributeSet) line: 51
Constructor.constructNative(Object[], Class, Class[], int, boolean) line: not available [native method] Constructor.newInstance(Object...) line: 415 PhoneLayoutInflater(LayoutInflater).createView(String, String, AttributeSet) line: 505
PhoneLayoutInflater(LayoutInflater).createViewFromTag(String, AttributeSet) line: 570
PhoneLayoutInflater(LayoutInflater).rInflate(XmlPullParser, View, AttributeSet) line: 623 PhoneLayoutInflater(LayoutInflater).inflate(XmlPullParser, ViewGroup, boolean) line: 408 PhoneLayoutInflater(LayoutInflater).inflate(int, ViewGroup, boolean) line: 320 PhoneLayoutInflater(LayoutInflater).inflate(int, ViewGroup) line: 276
PhoneWindow.setContentView(int) line: 207
MainActivity(Activity).setContentView(int) line: 1657
MainActivity.onCreate(Bundle) line: 20
Instrumentation.callActivityOnCreate(Activity, Bundle) line: 1047
ActivityThread.performLaunchActivity(ActivityThread$ActivityClientRecord, Intent) line: 1586
ActivityThread.handleLaunchActivity(ActivityThread$ActivityClientRecord, Intent) line: 1638
ActivityThread.access$1500(ActivityThread, ActivityThread$ActivityClientRecord, Intent) line: 117 ActivityThread$H.handleMessage(Message) line: 928 ActivityThread$H(Handler).dispatchMessage(Message) line: 99 Looper.loop() line: 123 ActivityThread.main(String[]) line: 3647 Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method] Method.invoke(Object, Object...) line: 507
ZygoteInit$MethodAndArgsCaller.run() line: 839 ZygoteInit.main(String[]) line: 597 NativeStart.main(String[]) line: not available [native method]

and here is the stack trace after Eclipse has stopped execution on account of the exception:

Thread [<1> main] (Suspended (exception RuntimeException)) ActivityThread.performLaunchActivity(ActivityThread$ActivityClientRecord, Intent) line: 1622
ActivityThread.handleLaunchActivity(ActivityThread$ActivityClientRecord, Intent) line: 1638
ActivityThread.access$1500(ActivityThread, ActivityThread$ActivityClientRecord, Intent) line: 117 ActivityThread$H.handleMessage(Message) line: 928 ActivityThread$H(Handler).dispatchMessage(Message) line: 99 Looper.loop() line: 123 ActivityThread.main(String[]) line: 3647 Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method] Method.invoke(Object, Object...) line: 507
ZygoteInit$MethodAndArgsCaller.run() line: 839 ZygoteInit.main(String[]) line: 597 NativeStart.main(String[]) line: not available [native method]

Any help would be highly appreciated.

Raidri
  • 17,258
  • 9
  • 62
  • 65
Kyre
  • 143
  • 2
  • 7

4 Answers4

7

When the debugger breaks like that, just continue execution (probably you'll need to do this 2 or 3 times). Then look at the LogCat output for a meaningful stack trace.

Ted Hopp
  • 232,168
  • 48
  • 399
  • 521
  • Thanks, that helps. After continuing execution a couple of times, I could indeed see a bunch of error messages in the LogCat output, including a line that specifically points to where the exception was thrown in *my* code. I could even double-click it and it brought me to that line in my code. =) – Kyre Mar 20 '11 at 14:01
4

Sounds to me like you should be wrapping your code in question in a try/catch block so you can (A) gracefully handle the exception and (B) Be able to set a breakpoint in the catch block and inspect your variables while debugging. Or am I misunderstanding?

edit:

As an example, if you have an Activity and you're in your onCreate (my Android-fu is a little rusty) and it's

public void onCreate(Bundle blahblah) {
  My code here
}

you would instead do

public void onCreate(Bundle blahblah) {
  try { 
    My code here
  } catch (Exception e) {
    Log.d(Do something to print your stacktrace here); <-- Set your breakpoint here
  }
}
MattC
  • 12,285
  • 10
  • 54
  • 78
  • I can't do that if I don't know which method causes the problem, and I can't just wrap every method implementation with try/catch blocks for the sake of debugging. – Kyre Mar 20 '11 at 14:08
  • Line 20 in MainActivity.onCreate seems to be a good place to start. – MattC Mar 21 '11 at 14:12
1

The first line in the Stack trace shows you where its blowing up. In your case:

Thread [<1> main] (Suspended (breakpoint at line 72 in GameView))
GameView.showMenu() line: 72
GameView.init() line: 59
GameView.(Context, AttributeSet) line: 51
Robby Pond
  • 73,164
  • 16
  • 126
  • 119
  • As I had stated, that stack trace was *prior* to when the exception was thrown, and I deliberately stopped on the line before. I can only do that when I already know which line is causing the problem, which is exactly what I wanted to know how to do. – Kyre Mar 20 '11 at 14:07
0

To me, that output doesn't look like it is actually the stacktrace of the exception. That just looks like the Thread information from the debug perspective. Try using logcat in either the ddms perspective or the ddms standalone tool to look at the actual exception that is thrown.

dave.c
  • 10,910
  • 5
  • 39
  • 62