可以使用已检查的异常抛出未检查的异常吗？

Question

I am running the following code:

import java.io.FileNotFoundException;
import java.io.IOException;

class Basic1 {
    int c;

    void calculation(int a, int b) throws Exception {
        c = a / b;
    }
}

class Basic extends Basic1 {
    void calculation(int a, int b) throws IOException {
        c = a / b;
        RuntimeException ae = new ArithmeticException();
        throw ae;
    }

    public static void main(String[] args) {
        int a = 10;
        int b = 0;
        int c;
        Basic ba = new Basic();
        try {
            ba.calculation(a, b);
        } catch (IOException e) {
            System.out.println("Zero can't be there in the denominator. : IoException");
        } catch (ArithmeticException e) {
            System.out.println("Zero can't be there in the denominator. : Arthimetic Exception");
        } catch (Exception e) {
            System.out.println("Zero can't be there in the denominator. : Exception");
        }
    }
}

The program is compiling successfully and outputting "Zero can't be there in the denominator. : Arthimetic Exception" (output is as expected).

My question is how is the program able to compile successfully? Why am I not getting an error when I throw an IOException while inside calculation() I am creating a RuntimeException object?

My second question is given that the program enters the catch (ArithmeticException e) clause, is the compiler deciding at run time which catch will execute? Do I understand correctly?

Answer 1

For your first question, methods using the throws E (where E is some arbitrary checked exception) construct don't have to throw anything. All it means is that anyone calling your method has to be able to handle E , which allows your method to throw E without handling it. This would otherwise be a compilation error. Usually, the documentation of your method specifies when E is thrown. In the words of the JLS:

Essentially, for each checked exception that can result from execution of the body of a method or constructor, a compile-time error occurs unless its exception type or a supertype of its exception type is mentioned in a throws clause in the declaration of the method or constructor.

This doesn't say you must throw the given checked exception within the method body. Note that you can use throws with unchecked exceptions, but this has no effect on the program, as unchecked exceptions may be thrown anywhere without being handled. That's the point of them.

In your code, you throw a RuntimeException . Any class extending RuntimeException (including itself) is unchecked by definition. ArithmeticException is one of these, so you may assign it to a variable of type RuntimeException and then throw it without specifying it in the throws clause.

For your second question, I'll assume that the compiler doesn't optimise away the various catch clauses. In that case, no, the catch which is executed is not determined at compile time. When any exception is thrown in your program, it propagates up the stack until it is caught. If it isn't, it halts execution and the stack trace is printed to System.err . Since an ArithmeticException is thrown, the first catch clause does not match but the second one does, so is executed. The third one ( catch (Exception e) ) would match, but order matters with catch clauses and only one is executed, so that clause is not executed here.

However, in this case, it is not inconceivable that the compiler optimises away your catch clauses and directs the program straight to the code in the catch (ArithmeticException e) clause, as your method will always throw ArithmeticException . It must be considered, however, that any line of code may throw some obscure error like OutOfMemoryError ; the compiler must allow for such edge cases when optimising.