loss exception in block catch

I run this code:

public class User {

    public static void main(String args[]) {
        int array[] = new int[10];
        int i = 1;
        try {
            System.out.println("try: " + i++);
            System.out.println(array[10]);
            System.out.println("try");
        } catch (Exception e) {
            System.out.println("catch: " + i++);
            System.out.println(array[10]);
            System.out.println("catch");
        } finally {
            System.out.println("finally: " + i++);
            Object o = null;
            o.hashCode();
            System.out.println("finally");
        }

    }
}

Result:
try: 1
catch: 2
finally: 3
Exception in thread "main" java.lang.NullPointerException at user.main(User.java:17)

in block catch - ArrayIndexOutOfBoundsException, but we loss this Exception, why?

回答1:

From the JLS

You can read about this in the JLS, Blocks and Statements, section "14.19.2 Execution of try-catch-finally". And I quote,

If execution of the try block completes abruptly for any other reason R, then the finally block is executed. Then there is a choice:
If the finally block completes normally, then the try statement completes abruptly for reason R.

If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and reason R is discarded). The example...

Therefore, the following (which is really condensed from the questioner's code) completes with an NPE, not the ExceptionTest thrown.

class Phinally
{
  static class ExceptionTest extends Exception
  { public ExceptionTest(String message) { super(message); }  }

  public static void main(String[] args) throws ExceptionTest
  {
    try {
      System.out.println("Foo.");
      throw new ExceptionTest("throw from try"); 
    } finally {
      throw new NullPointerException("throw from finally");
    }    
  }
}

A Sidebar about `try` with resources/ARM blocks

Difficulties reasoning about this in some common cases specifically with managing resources, and requiring nested try/catch/finally blocks, and nested inside finally blocks, are part of the reason for the "try with resource" feature in project COIN (to be integrated into Java "fairly soon"), about which you can read more about here.

This is one of many good reasons to invest the time in running a static analyzer like PMD, which finds and complains about this type of confusion -- though it might not catch the case in your code, I'm not sure.

Static Checking

Follow up on comment from @stacktrace: I ran the relevant code through PMD and FindBugs, trying both of the following:

finally { throw NullPointerException("Foo"); }

and

finally { Object o = null; System.out.println(o.toString()); }

For the former, PMD noticed and complained about an exception being thrown from a finally clause. FindBugs doesn't complain at all. For the latter, PMD complained about several things but nothing related ("LocalVariableCouldBeFinal", "StringToString", and "UselessOperationOnImmutable"). However, FindBugs noticed and complained about a null dereference. Moral of the story? Run both PMD and FindBugs!

Related on SO: Swallowing exception thrown in catch/finally. Can I avoid such cumbersome try/catch/finally...

回答2:

You have just stumbled upon an odd feature of Java, that if the finally block doesn't terminate properly, it hides any exceptions that were previously thrown.

This is by design, it is not a mistake.

回答3:

You last exception doesn't occur inside a try { } catch { } block so there is no catch { } or finally { } processing.