title: Throwing null in Java
body: <p>Working on <code>Android</code> I bumped into something like this:</p>
  
  <pre><code>    try {
           return someMethodThatThrowsExceptionA();
          } catch (ExceptionBthatExtendsExceptionA e) {
              // e is null but caught here.
          } catch (ExceptionA e) {
              // e is also null when caught.
          }
      }
  </code></pre>
  
  <p>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:</p>
  
  <ul>
  <li>The <code>Exception</code> is caught, but somehow is <code>null</code>. As per <a href="https://stackoverflow.com/questions/22378147/can-java-throw-a-null-reference-to-an-exception?lq=1">A</a> and <a href="https://stackoverflow.com/questions/17576922/why-can-i-throw-null-in-java?lq=1">B</a> , I thought that throwing <code>null</code> was impossible.</li>
  <li>The <code>Exception</code> is catched by a <code>catch block</code> for a <code>Subclass</code> of the <code>Exception</code> that the method throws ( <code>ExceptionBthatExtendsExceptionA</code> ).</li>
  </ul>
  
  <p>If I remove the catch block for <code>ExceptionBthatExtendsExceptionA</code>, the <code>Exception</code> is caught by the <code>ExceptionA</code> <code>catch block</code>, but is also <code>null</code>.</p>
  
  <p>Could you explain me</p>
  
  <ul>
  <li>How a <code>method</code> is throwing <code>null</code> without creating a <code>NullPointerException</code>? ----> Not possible as per <a href="http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.18" rel="nofollow noreferrer">Java's specification</a>.</li>
  <li>How is a <code>null</code> <code>Exception</code> correctly catched (casted?) to a specific <code>catch block</code>? How can can the <code>catch block</code> recognize that <code>null</code> is an instance of a <code>Subclass</code> and not of its parent <code>Class</code>? ----> Same as question before.</li>
  <li>Are these allowed <code>Java</code> behaviors or is this maybe a bug related to <code>Android Studio</code> or <code>Dalvik</code> / <code>ART</code>? ----> Possibly.</li>
  </ul>
  
  <p>Edit:</p>
  
  <p>It seems that this is a bug for the debugger in Android Studio 1.4.</p>
  
  <p>After debugging and testing with different devices I've found this:</p>
  
  <ul>
  <li>The error doesn't happen when not debugging the app.</li>
  <li>It also doesn't present when debugging or not on <code>Lollipop</code> devices.</li>
  <li>It has only been present when debugging <code>4.3</code> or <code>4.4</code> devices so far, if I unplug the device, the app behaves as expected.</li>
  </ul>
  
  <p>As more information for the implementation, the try/catch block described before is inside an <code>AsyncTask</code>'s <code>doInBackground()</code>, and <code>someMethodThatThrowsExceptionA()</code> is a method constructs a query and calls internally a method that executes a <code>Fusiontables.Query.Sql</code> and throws <code>ExceptionA</code> , in this case <code>IOException</code> and it's subclass <code>UserRecoverableAuthIOException</code> (<code>ExceptionBthatExtendsExceptionA</code>) , so <code>Http</code> communications happen inside.</p>
  
  <p>Also, when I try to catch the error inside <code>someMethodThatThrowsExceptionA()</code>, sometimes the <code>Exception</code> catched is not <code>null</code>, but it always ends up being <code>null</code> when I throw it again and catch it in the <code>catch block</code> of method that called <code>someMethodThatThrowsExceptionA()</code>.</p>
  
  <p>Since the <code>Exception</code> is correctly interpreted as an instance of <code>UserRecoverableAuthIOException</code> (<code>ExceptionBthatExtendsExceptionA</code>) and the code enters into its corresponding <code>catch block</code>, the bug has to be happening after this and before the debugger figures out the value of the exception inside the block.</p>