Try the following:
Create a HelloWorld application.
Add a Log statement to the end of onCreate:
public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); Log.d("HelloWorldActivity.onCreate()", "setContentView() completed"); }
Place a breakpoint on the Log statement.
Run the app in the emulator and note it works and step to see the Logged entry in the LogCat window of Eclipse.
Change the HelloWorldActivity to extend from ListActivity instead of Activity.
public class HelloWorldActivity extends ListActivity {
My question is NOT why this fails. My question is, how would you go about debugging this failure? All I see in the Eclipse Debug pane is a RuntimeException. I see LogCat has a bunch of messages, but it's huge and I've searched it but can't find anything to indicate what's wrong or where in my code the exception happened. I can't find a way to display the message inside the RuntimeException or a stack trace to know which line of code initiated the exception.
I assume there must be better ways to use the tools to find errors, but I'm new and can't seem to figure out a better way to debug besides wrapping everything I code in a try/catch. I would have expected to find a message in LogCat generated by the throwing of the exception. I would have expected the Debug window to allow you to inspect the exception's contents. I'm not saying that such techniques don't exist, I'm saying I'm having trouble figuring out as a beginner how to debug and asking what techniques do exist and how do I use them?
So, simply put:
Multiple suggestions and discussion are welcomed. :)
I would have included my LogCat contents, but it's so large that's not reasonable. You should be able to easily reproduce this yourself, so I left it out. It is possible something is in LogCat to help me, but because it's so large with even running a small program, I would need a hint as to what to search for and how to interpret it when hitting an exception thrown from an API call. I see other posts that state something should be in LogCat, which while might be true, I'm not finding anything myself. If you think something should be in LogCat, please run the test yourself and copy the lines into your response that I should be finding.
Thanks.
========
Summary techniques list so far is as follows:
Invasive Techniques: 1. Place a Toast in code locations where you want to see you you've executed. 2. Place try/catch around code where you think there's a possibility of an Exception being thrown. 3. Comment out code and recompile and retest.
Non-Invasive Techniques: 1. Use the debugger. Breakpoints, variable inspection... 2. Monkey stress tester. 3. Download Android source library. 4. Use LogCat filters to see if a "Caused By" is listed.
Unclear if Available: 1. Debug version of Android library that has additional logging, assertions or other additional help. 2. Ability to inspect an Exception in Eclipse through the Debug pane or other techniques. 3. A way to define a more global try/catch exception handler. 4. Ability to debug through the Android library source code.
Not Available: 1. A non-invasive way to view the contents of an Exception or where the Exception happened.
hey, Ineresting question. Well, first tip, you can filter what logcat tells you. For instance, you make it just show you errors by clickin in the red (e). It also tells you where the error happened if you run your app in debug mode. It can either point you directly to your code or to android sdk. Knowing what android package caused the error is a big help.
These two just pop into my mind. hope it helps!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With