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

Предложение throws является частью контракта метода. Он требует, чтобы вызывающий метод вел себя так, как будто указанное исключение может быть вызвано методом (т. е. либо перехватывало исключение, либо объявляло собственное предложение throws).

Возможно, что первоначальная версия метода не выдает исключение, указанное в предложении throws, но будущая версия может выдать его без нарушения API (т. е. любой существующий код, вызывающий метод, все равно пройдет компиляцию).

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

Первый пример:

Предположим, у вас есть этот код, который использует methodB:

private static void methodA() {
    methodB(); // doesn't have throws IOException clause yet
}

Если позже вы захотите заменить methodB на throw IOException, methodA перестанет проходить компиляцию.

Второй пример:

Предположим, у вас есть этот код, который использует methodB:

private static void methodA() {
    try {
        methodB(); // throws IOException
    }
    catch (IOException ex) {

    }
}

Если вы удалите предложение throws из будущей версии methodB, methodA больше не будет проходить компиляцию.

Этот пример не очень интересен, когда methodA равно private, потому что его можно использовать только локально (внутри того же класса, где легко модифицировать все вызывающие его методы).

Однако, если он становится public, вы не знаете, кто использует (или будет использовать) ваш метод, поэтому вы не контролируете весь код, который может сломаться в результате добавления или удаления предложения throws.

И если это метод экземпляра, есть еще одна причина разрешить предложение throws, даже если вы не выдаете исключение — метод может быть переопределен, а переопределяющий метод может выдать исключение, даже если реализация базового класса этого не делает.

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

Предположим, вы пока предоставляете фиктивную реализацию метода, но знаете, что позже фактическая реализация потенциально вызовет исключение IOException. Если бы компилятор запретил вам добавлять это предложение throws, вы были бы вынуждены переработать все вызовы (рекурсивно) этого метода, как только вы предоставите фактическую реализацию метода.

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

Используйте throws для удобочитаемости и указания возможности исключения, а также используйте try/catch, чтобы сообщить программе, что делать в случае исключения.

1. Метод B выдает IOException, поэтому метод, вызывающий метод B, отвечает за перехват исключения, которое будет сгенерировано методом B. Попробуйте вызвать метод B из других методов, он попросит вас поймать его или повторно сгенерировать исключение IOException. Где-то вам придется поймать IOException в цепочке (в блоке try/catch). Таким образом, вы не получите ошибку времени компиляции.

   private void sampleMethod(){ try { methodB(); } catch (IOException e) { // Автоматически сгенерированный блок catch TODO e.printStackTrace(); } }

2. try/catch в methodA, по общему признанию, проглатывает исключение, что означает, что methodA отвечает за перехват исключения в блоке try/catch. «Каждый оператор в любой Java-программе должен быть доступен, т. е. каждый оператор должен выполняться хотя бы один раз». Таким образом, вы получите ошибку компилятора, поскольку в вашем блоке try нет кода, вызывающего IOException.