0

I am fairly new to android, java and eclipse here. When my code run into some exception, the program crashes and I got a big chunk of error information in the logcat.

The logcat shows really too much information. I have to scroll all the way to the top to see where exactly the exception was original caused. That gives me a headache every time. Is there any option I can set to reduce the amount of useless information in the logcat? And, there is one more annoying thing. When the program first stopped running, I don't see anything in the log cat. I have to click the "Resume" button twice in order to see the large chunk of information in log cat.

The second problem is that when the program breaks, the stack trace I got doesn't contain the original point where the exception was thrown. It looks the exception was thrown and caught by the outer level code in android system. That stack trace is completely useless and I can't use it to inspect the local variables within the function causing the original exception.

I read some posts regarding setting breakpoints in specific exceptions. That works if I know what is the original type of exception. But the truth is, after the original exception was caught by the outer level system code, all I can see in the debugger is a "runtimeException".

Thanks for any tips to help the debugging in eclipse more efficient.

Stephen Cheng
  • 964
  • 2
  • 11
  • 24
  • possible duplicate of [What is a stack trace, and how can I use it to debug my application errors?](http://stackoverflow.com/questions/3988788/what-is-a-stack-trace-and-how-can-i-use-it-to-debug-my-application-errors) – panini Aug 19 '14 at 04:22
  • 1
    You are asking too general question and making unsubstantiated statements. I've seen multiple cases when Android stack trace was extremely useful in identifying the culprit. – PM 77-1 Aug 19 '14 at 04:25
  • Are you actually filtering by process?, it should filter your app's debugging by default, going by your description, it seems that you are seeing a normal stack trace. – Eduardo Naveda Aug 19 '14 at 04:41
  • I did find the original type of exception in the log cat after a more careful look. It'd be more helpful to list the chain of exceptions in a way easier to read. For example, the exception itself can be rendered as green while the stack trace can be rendered as red. It'd be even better to list the stack trace as expandable child items under each exception. Maybe I am excepting too much from eclipse. – Stephen Cheng Aug 19 '14 at 05:02

1 Answers1

1

The SDK tools for ADT has been updated to, in most cases, give you ability to double click on the bad line in the log and it will bring you to the offending line of code.

So make sure you have the latest sets of tools loaded in your SDK.

Here's an excerpt from a null pointer exception in the logcat.

08-19 05:13:33.746: D/AndroidRuntime(1002): Shutting down VM
08-19 05:13:33.746: W/dalvikvm(1002): threadid=1: thread exiting with uncaught exception (group=0xa6306288)
08-19 05:13:33.746: E/AndroidRuntime(1002): FATAL EXCEPTION: main
08-19 05:13:33.746: E/AndroidRuntime(1002): java.lang.NullPointerException
08-19 05:13:33.746: E/AndroidRuntime(1002):     at com.hlresidential.aceyourexam.MainActivity.onSKUChange(MainActivity.java:1107)
08-19 05:13:33.746: E/AndroidRuntime(1002):     at com.hlresidential.aceyourexam.MainActivity$10.onClick(MainActivity.java:1061)

If you double click on the second to last line, you should be brought to the offending line of source code.

If you have a 'CAUSED BY' statement in your logcat, typically it's the following statement that should be double clicked on.

Hope this helps.

Peter Birdsall
  • 3,159
  • 5
  • 31
  • 48
  • Yes. It does bring me back to the line. But since the exception has been handled by outer-level code from android.jar, I can't watch the variables in the original function. I would have to set an exception breakpoint in order to directly catch the original exception with the debugger, if I want to inspect the variables. – Stephen Cheng Aug 20 '14 at 17:59
  • The only other thing I can think of is, did you also change the URI of your content provider, if your using one. – Peter Birdsall Aug 21 '14 at 05:25