Why does the Java compiler allow exceptions to be listed in the throws section that it is impossible for the method to throw

Question

The Java compiler seems inconsistent if there is some code that clearly can not throw an exception, and you write surrounding code that declares that the code can throw that

Answer 1

Just a try !!

For second case there might be a possibility that some other class overrides this method in the future and a code is written inside that which can throw this exception.

Answer 2

Throws does not handle exception, It indicates the throwing exception upwards from where method will be called. In other words it will just pass exception to the caller.

While try...catch block handles the exception, and that is why Java compiler will check if there is any exception to handle which is being caught in catch block or not.

Those are two different thing, One is Throwing and another is Handling the exception and compiler will make his nose tilted on second one only...:p

From the JavaDoc :

Exception handlers can do more than just print error messages or halt the program. They can do error recovery, prompt the user to make a decision, or propagate the error up to a higher-level handler using chained exceptions.

So, by providing try...catch implementation, you are requesting compiler to do some more thing than just printing exception.

Another specific reason :

public void testException() throws FileNotFoundException {
    File file = new File("test.txt");
    System.out.println(file.exists());
    Scanner scanner = new Scanner(file);
}

If you will observe the compiled code of above example by javap -c Test.class you will find an Exception table will be created.

  public static void testException();
    Code:
       0: new           #2                  // class java/io/File
       3: dup           
       4: ldc           #3                  // String test.txt
       6: invokespecial #4                  // Method java/io/File."<init>":(Ljava/lang/String;)V
       9: astore_0      
      10: getstatic     #5                  // Field java/lang/System.out:Ljava/io/PrintStream;
      13: aload_0       
      14: invokevirtual #6                  // Method java/io/File.exists:()Z
      17: invokevirtual #7                  // Method java/io/PrintStream.println:(Z)V
      20: new           #8                  // class java/util/Scanner
      23: dup           
      24: aload_0       
      25: invokespecial #9                  // Method java/util/Scanner."<init>":(Ljava/io/File;)V
      28: astore_1      
      29: goto          37
      32: astore_1      
      33: aload_1       
      34: invokevirtual #11                 // Method java/io/FileNotFoundException.printStackTrace:()V
      37: return        
    Exception table:
       from    to  target type
          20    29    32   Class java/io/FileNotFoundException

So, When compiler won't find any code that is not throwing exception in try block, an compile time error will be there.

and Exception table will not be generated in case of throws.

Answer 3

Since you wanted other views -

Consider two implementations of the same signature in two different subclasses.

For example, (a made up example),

public class StudentLoader {
    public abstract Student readStudentData() throws SQLException, IOException;

    public static void main(String args[]) {
        StudentLoader loader = getStudentLoader (); //may return any subclass instance
        try {
            Student s = loader.readStudentData();
        }
        catch(IOException e) {
            //do something
        }
        catch(SQLException e) {
            //do something
        }
    }
}

public class StudentFileReader extends StudentLoader {
    public Student readStudentData() throws IOException {
        //read from a file
    }
}

public class StudentDBReader extends StudentLoader {
    public Student readStudentData() throws SQLException {
        //read from DB
    }
}

why compiler do allow to write exceptions in throws section even if it can not be thrown?

Even though the subclass implementation StudentDBReader is not throwing IOException, the parent class StudentLoader still has to say throws IOException because other implementations of StudentLoader may throw it. So even though the exception may not be thrown by the method, you have a way of indicating to the caller using StudentLoader reference (that points to either of the two subclasses instance) that the caller must handle these exceptions.

In your snippet 1 showing method g(), there is no scope of inheritance. The code is right there in the try block. If any statement in try is throwing a checked Exception, you will have to handle it. In case of throws clause, scope for inheritance has to be allowed. Compiler cannot decide which version of readStudentData( ) will be called at runtime.

I would expect that compiler should give an error in case of static methods, if Exception mentioned in throws clause is not thrown, since static methods do not participate in inheritance. I am not sure why throws clause in static methods can contain Exceptions which are never thrown in implementation. It will not be overridden anyway, so why not throw error here? There might be something I am missing.

Answer 4

public class UnreachableCatchBlock {

    public static void main(String[] args) {
        UnreachableCatchBlock ucb = new UnreachableCatchBlock();
        System.out.println(ucb.getClass().getName() + " started.");
//      ucb.method1();
        ucb.method2();
    }

    private void method1() {
        try {
            System.out.println(getClass().getName() + ".method1() started.");
        } catch (FileNotFoundException e) {//any checked exception

        }
    }

    private void method2() {
            System.out.println(getClass().getName() + ".method2() started.");
    }

}

Above code compiles and runs as explained in @Raedwald answer.

I don't suggest this as an answer, just a place to post the code that I attempted to include in comments.

Answer 5

The compiler allows this because the throws clause of the method is part of the signature of the method, rather than part of its implementation. It is possible that the implementation might change at some point, while keeping the signature the same. An old implementation might have thrown a checked exception, but the new one might not. Or the designer of the signature might have wanted to give the implementer the flexibility to throw a checked exception when that is not always necessary.