Почему компилятор Java позволяет перечислять исключения в разделе throws, которые метод не может выбросить

Компилятор допускает это, поскольку предложение throws метода является частью сигнатуры метода, а не его реализации. Возможно, что реализация в какой-то момент может измениться при сохранении подпись такая же. Старая реализация могла вызвать проверенное исключение, а новая - нет. Или разработчик подписи мог захотеть предоставить разработчику гибкость для создания проверенного исключения, когда это не всегда необходимо.

Просто попробуйте !!

Во втором случае может существовать вероятность того, что какой-либо другой класс переопределит этот метод в будущем, и внутри будет написан код, который может вызвать это исключение.

Поскольку вам нужны были другие взгляды -

Рассмотрим две реализации одной и той же сигнатуры в двух разных подклассах.

Например, (выдуманный пример),

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
    }
}

почему компилятор позволяет записывать исключения в раздел бросков, даже если его нельзя выбросить?

Несмотря на то, что реализация подкласса StudentDBReader не выбрасывает IOException, родительский класс StudentLoader все равно должен сказать throws IOException, потому что другие реализации StudentLoader могут его выбросить. Таким образом, даже если исключение не может быть создано методом, у вас есть способ указать вызывающей стороне с помощью ссылки StudentLoader (которая указывает на любой из двух экземпляров подкласса), что вызывающая сторона должна обрабатывать эти исключения.

В вашем фрагменте 1, показывающем метод g(), нет области наследования. Код находится прямо здесь, в блоке try. Если какой-либо оператор в try выбрасывает отмеченное исключение, вам придется его обработать. В случае предложения throws должна быть разрешена возможность наследования. Компилятор не может решить, какая версия readStudentData( ) будет вызываться во время выполнения.

Я ожидал, что компилятор должен выдать ошибку в случае статических методов, если исключение, указанное в предложении throws, не выбрано, поскольку статические методы не участвуют в наследовании. Я не уверен, почему предложение throws в статических методах может содержать исключения, которые никогда не выбрасываются при реализации. В любом случае он не будет отменен, так почему бы не выдать здесь ошибку? Возможно, я что-то упускаю.

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.");
    }

}

Вышеупомянутый код компилируется и запускается, как описано в ответе @Raedwald.

Я не предлагаю это в качестве ответа, просто место для публикации кода, который я пытался включить в комментарии.

Throws не обрабатывает исключение. Он указывает на выброс исключения вверх, откуда будет вызван метод. Другими словами, он просто передаст исключение вызывающей стороне.

Блок try...catch обрабатывает исключение, и поэтому компилятор Java проверяет, есть ли какое-либо исключение для обработки, которое попадает в блок catch или нет.

Это две разные вещи: одна - это бросок, а другая - обработка исключения, и компилятор будет наклонять нос только ко второму ...: p

Из JavaDoc:

Обработчики исключений могут делать больше, чем просто выводить сообщения об ошибках или останавливать программу. Они могут выполнять исправление ошибок, предлагать пользователю принять решение или передавать ошибку обработчику более высокого уровня с помощью связанных исключений.

Итак, предоставляя try...catch реализацию, вы запрашиваете у компилятора нечто большее, чем просто вывод исключения.

Другая конкретная причина:

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

Если вы посмотрите на скомпилированный код из приведенного выше примера javap -c Test.class, вы обнаружите, что будет создана таблица исключений.

  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

Итак, когда компилятор не найдет код, который не генерирует исключение в блоке try, будет ошибка времени компиляции.

и таблица исключений не будет создана в случае throws.