开发者

Why can't the android debugger provide useful info?

开发者 https://www.devze.com 2023-01-23 09:57 出处:网络
Once again I\'ve hit a brick wall when debugging my android application. This problem usually manifests when you have errors in the startup code of your activity.

Once again I've hit a brick wall when debugging my android application.

This problem usually manifests when you have errors in the startup code of your activity.

In this case, somewhere after the constructor of my custom SurfaceView class I get presented with this worthless text:

Thread [<3> main] (Suspended (exception RuntimeException))  
    ActivityThread.performLaunchActivity(ActivityThread$ActivityRecord, Intent) line: 2596  
    ActivityThread.handleLaunchActivity(ActivityThread$ActivityRecord, Intent) line: 2621   
    ActivityThread.access$2200(ActivityThread, ActivityThread$ActivityRecord, Intent) line: 126 
    ActivityThread$H.handleMessage(Message) line: 1932  
    ActivityThread$H(Handler).dispatchMessage(Message) line: 99 
    Looper.loop() line: 123 
    ActivityThread.main(String[]) line: 4603    
    Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method]  
    Method.invoke(Object, Object...) line: 521  
    ZygoteInit$MethodAndArgsCaller.run() line: 860  
    ZygoteInit.main(String[]) line: 618 
    NativeStart.main(String[]) line: not available [native method]  

Which of course doesn't have anything to do with my code.

I've even tried to stepping through each line of my code, but this error happens somewhere in between th开发者_如何学JAVAe method calls.

I'm sure this is a simple error, but the fact that the debugger acts like this is a major annoyance and I know for a fact I will hit more of these errors.

Thanks.

Edit:

I found the problem. A simple null reference. The question remain though, why couldn't the debugger show me this nullpointerexception?


I feel your pain. The only way I know of is to let the program continue and force close, then read the log in the logcat pane. This appears to happen in all code which is called from an event passed down through the native layer, which as far as I can tell is just about everything.

I first let the program crash, then read the log to figure out where to put a breakpoint, then restart the app and inspect the values at the breakpoint. This is extremely frustrating.


You are looking at the current stack trace in the debugger, so it shows the current state of the program's execution. To see errors and stack traces related to exceptions, you need to look at the logs (open the "logcat" view in Eclipse, or use adb logcat in a shell.)


The debugger is breaking on the first uncaught exception, not the original exception. The logcat output has the full thing.

See also this older answer.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号