What's wrong with debugging in Eclipse on Android? [duplicate]

Question

Possible Duplicate:
Seemingly useless debugging environment for Android

I've obviously been spoiled by Visual Studio, because although I'm just learning Android and the Eclipse environment, debugging apps in Eclipse is becoming a serious detriment to further development.

For example, Eclipse will compile this divide by zero just fine:

public class Lesson2Main extends Activity {     /** Called when the activity is first created. */     @Override     public void onCreate(Bundle savedInstanceState)     {         super.onCreate (savedInstanceState);          int i = 1 / 0;          TextView tv = new TextView (this);         tv.setText ("Hello, Android!");         setContentView (tv);     } } 

And then, when it executes it under the debugger, I will get a full screen of useless debug info, non of which actually points me to the specific line containing the error.

The stackTrace is null within the exception ('e') info tree, and it simply states a message stating 'ArithmeticException'. (that's nice, how about you point me in the direction of where you found it!?)

I've looked all over the screen and am baffled that this IDE can't get this right. Does developing with Eclipse resort everyone back to 1991 with printf() like logging at every interval then to track down bugs? Seriously.

Is there a configuration or plug-in that I'm missing to help with this?

I haven't tested this case with XCode, but if the iPhone dev. IDE handles this more like Visual Studio, then no wonder the Android marketplace has so few apps.

I'm excited about Android, but it seems that Eclipse is getting in the way.

Answer 1

Yes, you've missed one of the very important plug-ins for Eclipse called "LogCat". It catches all the debugging logs that your Android program gives, whether it's running on the Emulator or a real phone. The latter obviously requires that the phone be plugged in to the computer, and less-obviously, the setting in Application -> Development -> Enable USB Debugging be enabled.

The LogCat messages give you the full breakdown of what caused the error, including the line number. To open LogCat in Eclipse, go to Window -> Show View -> Other -> Android (one of the folders in the list) -> LogCat. Then dock the LogCat window somewhere where you can see it easily, and Eclipse will remember that location and open it up again next time your start it.

(Sometimes LogCat and the Emulator get disconnected from each other. The simple way to fix that is just to close Eclipse and the emulator, then restart them both.)

Answer 2

(There's too much to say in a comment, so I'm writing this up as an answer.)

You can configure Eclipse to stop on exceptions that are caught, uncaught, or both. By default, Eclipse will break on any uncaught exception, and will ignore all caught exceptions (i.e. anything that is snagged by a try/catch block).

Things get a little weird for Android because you're running in an application framework, not a stand-alone application. As you can see from the stack trace posted above, the exception was actually caught by ActivityThread. This means that your initial exception is considered "caught", and won't trip Eclipse's break-on-uncaught handling until ActivityThread re-throws it. For this reason, the stack you see in the debugger when it stops is nowhere near your code.

Since you know you're getting an ArithmeticException, you can have it break on "caught" instances of that exception, and it will stop at the point of the throw. (Don't have it break on all caught exceptions -- you'll be hitting "resume" endlessly.)

As far as the logging being "late", if the debugger let the program continue to execute until the logging happened, you wouldn't be able to debug at the point of the throw.