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? Ie 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. Eg 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

Answer 3

I know this question was posted a while ago, and many times too! I fell into this trap yesterday and I thought I'll post what I found.

Problem definition: I used the following code

public class myAppActivity extends Activity
{
   /** Called when the activity is first created. */
   @Override
   public void onCreate(Bundle savedInstanceState)
   {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.main);
      try { -- lots of code -- }
      catch (Exception ex) {
          Log.e ("eTutorPrism Error", "Caught this exception " + ex);
          ex.printStackTrace();
      }
   }
}

Symptom was that 'ex' was always null and resume will give NullPointerException, although the actual exception was an IllegalArgumentException in a call made into another class from the code above.

ISSUE: onCreate() code does not display the exception caught. instead it shows exception = null.

Solution: do NOT use too much processing in onCreate(). Move as much as possible to another thread. So I changed the code to look like the following. voila, it works!!! I can see the actual exception displayed in the Logcat.

public class eTutorPrismAppActivity extends Activity
{
   /** Called when the activity is first created. */
   @Override
   public void onCreate(Bundle savedInstanceState)
   {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.main);

       eTutorPrismTest myTest = new eTutorPrismTest (getApplicationContext());
       myTest.start();
   }
}

class eTutorPrismTest extends Thread
{
   private Context m_AppContext = null;

   public eTutorPrismTest (Context appContext)
   {
      m_AppContext = appContext;
   }

   public void run ()
   {   
      -- lots of code that needs appContext --
   }
}

Answer 4

I am unsure of what causes this -- it could be an Eclipse bug as stated earlier. Regardless of the cause, I did find a workaround that seems to work. I hope it is useful to others as well.

After the exception is caught, assign it to another variable. The assigned variable should contain the correct Exception in the debugger.

SpecificException assignedVar = null;
try {
    ...
}
catch (SpecificException exc) {
    assignedVar = exc; // <-- exc comes up null in the debugger, but assignedVar will be the correct object.
}

Hope this works for others as a workaround.

Answer 5

Android does not always throws exception in a Throwable . It actually drives all the exceptions to the catLog . There you will find details of your exceptions even if in the catch block your exception is null .

You can easily access the catlog console from eclipse and filter to view the errors only

UPDATE:

Your breakpoint should be inside the catch block