0

Working on Android I bumped into something like this:

    try {
         return someMethodThatThrowsExceptionA();
        } catch (ExceptionBthatExtendsExceptionA e) {
            // e is null but caught here.
        } catch (ExceptionA e) {
            // e is also null when caught.
        }
    }

While I still need to dig out the reasons why the exception is thrown inside many method calls, there are two very surprising things here for me:

  • The Exception is caught, but somehow is null. As per A and B , I thought that throwing null was impossible.
  • The Exception is catched by a catch block for a Subclass of the Exception that the method throws ( ExceptionBthatExtendsExceptionA ).

If I remove the catch block for ExceptionBthatExtendsExceptionA, the Exception is caught by the ExceptionA catch block, but is also null.

Could you explain me

  • How a method is throwing null without creating a NullPointerException? ----> Not possible as per Java's specification.
  • How is a null Exception correctly catched (casted?) to a specific catch block? How can can the catch block recognize that null is an instance of a Subclass and not of its parent Class? ----> Same as question before.
  • Are these allowed Java behaviors or is this maybe a bug related to Android Studio or Dalvik / ART? ----> Possibly.

Edit:

It seems that this is a bug for the debugger in Android Studio 1.4.

After debugging and testing with different devices I've found this:

  • The error doesn't happen when not debugging the app.
  • It also doesn't present when debugging or not on Lollipop devices.
  • It has only been present when debugging 4.3 or 4.4 devices so far, if I unplug the device, the app behaves as expected.

As more information for the implementation, the try/catch block described before is inside an AsyncTask's doInBackground(), and someMethodThatThrowsExceptionA() is a method constructs a query and calls internally a method that executes a Fusiontables.Query.Sql and throws ExceptionA , in this case IOException and it's subclass UserRecoverableAuthIOException (ExceptionBthatExtendsExceptionA) , so Http communications happen inside.

Also, when I try to catch the error inside someMethodThatThrowsExceptionA(), sometimes the Exception catched is not null, but it always ends up being null when I throw it again and catch it in the catch block of method that called someMethodThatThrowsExceptionA().

Since the Exception is correctly interpreted as an instance of UserRecoverableAuthIOException (ExceptionBthatExtendsExceptionA) and the code enters into its corresponding catch block, the bug has to be happening after this and before the debugger figures out the value of the exception inside the block.

Community
  • 1
  • 1
buzoherbert
  • 1,537
  • 1
  • 12
  • 34
  • This happens when the exception propagated from called methods is not handled properly. check the method someMethodThatThrowsExceptionA() for the thrown exception. – Vivek Singh Oct 26 '15 at 07:31
  • 4
    Please post the content of someMethodThatThrowsExceptionA() method. It would be helpful. – Crusaderpyro Oct 26 '15 at 07:39
  • 3
    `e` is not null. [This is not possible](http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.18): "If evaluation of the Expression completes normally, producing a null value, then an instance V' of class NullPointerException is created and thrown instead of null." Its *message* may be null. If `e` was null you couldn't catch it, and you couldn't throw it either. – user207421 Oct 26 '15 at 07:51
  • Did you take a look at: http://stackoverflow.com/questions/8400711/java-exception-itself-is-null – Jozua Oct 26 '15 at 07:55
  • Thank you @Crusaderpyro , My concern is how was this situation possible regardless of the actual code I'm debugging now. – buzoherbert Oct 26 '15 at 08:30
  • @VivekSingh Thank you. My question is not about the contents of my code, but on the possibility of null exceptions in Java/Android as a more general concern. – buzoherbert Oct 26 '15 at 08:32
  • @EJP That is what I thought, but I'm on exactly that situation... – buzoherbert Oct 26 '15 at 08:32
  • @Jozua Thank you, I'm checking this option now. – buzoherbert Oct 26 '15 at 08:33
  • @buzoherbert The only way you can be 'on exactly that situation' is via a violation of the [Java Language Specification](http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.18), and therefore via a major platform bug. But it isn't plausible. How did the JVM know that `null` was an `Exception` as opposed to an `Error` or a `Throwable`. It simply is not plausible. – user207421 Oct 26 '15 at 08:52
  • Can you please post the content of method from which exception is occurring or propagated. – Vivek Singh Oct 26 '15 at 09:09
  • Thanks everyone for the insight. I added more information based on your advice. It seems that this is a bug with Android Studio and some specific versions of Android and not something allowed by the Java specification. – buzoherbert Oct 27 '15 at 04:53
  • 1
    "The error disappears when not debugging the app.". No. **The 'error' isn't present in the first place.** It is only an artefact of the debugger. It probably uses `Exception.toString()` to display the error. "The bug has to be happening after this and before the debugger figures out the value". No. The error happens **when** "the debugger figures out the value". To prove the 'error' realy exists you would have to show some *output* from the program that says so. Not just a debugger console. I spent most of yesterday fighting an erronous debugger display. They happen. – user207421 Oct 27 '15 at 04:56

0 Answers0