Caught Throwable or Exception is null

Question

A similar question was asked here for two times and never there was any answer. Or the answer was: "it is impossible!" Sorry, it is possible too much:

try{
    ...
    // the line that causes the error
    LinearLayout cell = (LinearLayout) inflater.inflate(R.layout.channels_list_cell, column);
    ...
}
catch(Throwable e){
    Toast.makeText(this, e.toString(), Toast.LENGTH_LONG).show(); < breakpoint here!
}

At the breakpoint e is null. How can I seek for the error, please? Very possibly it is not the problem of java or Android, but of the Eclipse debugger, that itself needs debugging badly. But what have I to do, except changing to a different IDE? Any ideas? Beforehand grateful.

I have tried Throwable, Exception, RuntimeException. The result is the same.

An attempt to step over breakpoint causes NullPointerException, so, e seems really null at that moment already. Where could it be lost?

Edit: I bring my gratitude to everybody and +1 to every answerer. It was an Eclipse bug. After restart Eclipse the Exception is not null anymore, it is a normal RuntimeException: Binary XML file line #15: You must supply a layout_width attribute. It would be another problem to be solved, but that one is solved.

Answer 1

If the exception you caught was a NullPointerException, the getMessage() method returns "null" which may be confusing. I know that this has sometimes confused me!

In the debugger, you should be able to select e and see a type and its fields. Also, another way to debug when things get really confusing is to go

 e.printStackTrace();

(note - I'm not an Android guru so if this works differently on Android somebody please comment!)

Answer 2

Have you verified whether e is actually null or not? I.e. by adding something like if (e == null) Log.d("Exception is null"). I would then check if the log statement gets triggered both during normal execution and while debugging. If the results are different between the two, it would indicate a VM bug (unlikely, but possible). If the message doesn't get triggered in either case, then it's likely a debugger issue.

A few thoughts on further things you can try to debug the issue:

• Try something like jdb and see if you get the same behaviour

• You could get a dump of the jdwp communications between the debugger and the device, and see what's going on at that level. Maybe use wireshark or tcpdump and grab the data going over the usb bus to the device.

• You could try adding some debug statements to dalvik itself. E.g. grab a copy of AOSP and build an emulator image, and then add some debugging statements to dalvik to try and track down what's going on.

• You could attempt to do some sort of scripted jdwp session with the device

• You could look at the bytecode (baksmali/dexdump/dedexer), to see if anything looks funny