Краткий ответ

Метод-наследник может не объявлять checked-исключения, объявлять только их подтипы или сохранять совместимый набор. Добавить новое checked-исключение либо расширить тип уже объявленного нельзя. Для unchecked-исключений таких ограничений нет: переопределяющий метод может объявлять их независимо от throws базового метода.

Исторический контекст

Checked-исключения появились в Java как механизм явного описания условий, которые вызывающий код должен обработать или передать дальше. При наследовании это описание стало частью контракта: код, работающий со ссылкой базового типа, должен оставаться корректным для любого допустимого объекта-наследника.

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

Постановка проблемы

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

Если реализация-наследник добавит SQLException, такой вызов может привести к checked-исключению, о котором контракт базового типа ничего не сообщает. Поэтому компилятор запрещает подобное переопределение; иначе статическая проверка исключений теряла бы смысл.

Подробное решение

Для каждого checked-исключения, объявленного переопределяющим методом, должен существовать совместимый тип в throws переопределённого метода: фактический тип должен быть тем же или его подтипом. Метод также может убрать часть исключений или полностью отказаться от throws.

Например, FileNotFoundException допустим при переопределении метода, объявляющего IOException, потому что это его подтип. Exception недопустим, поскольку он шире IOException. Если базовый метод не объявляет checked-исключений, переопределяющий метод не может добавить ни одного.

Проверяются именно checked-исключения. RuntimeException, Error и их подтипы не подчиняются этому ограничению, даже если явно указаны в throws. Однако отсутствие ограничения компилятора не означает отсутствия API-контракта: неожиданное unchecked-исключение может нарушить ожидания клиентов.

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

import java.io.*;

class Reader {
    void read() throws IOException { }
}

class FileReader extends Reader {
    @Override
    void read() throws FileNotFoundException { }

    void log() throws RuntimeException { }
}

В примере FileNotFoundException допустим как подтип IOException, а RuntimeException не ограничен правилами checked-исключений. Объявление throws Exception в FileReader.read() было бы ошибкой компиляции.

Ситуация из практики

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

Возможны три подхода. Можно обернуть SQLException в unchecked-исключение, сохранив сигнатуру, но тогда вызывающий код потеряет обязательную проверку recoverable-сценария. Можно преобразовать её в совместимое checked-исключение, например в доменное исключение-наследник объявленного типа, сохранив контролируемый контракт, но добавив слой преобразования.

Третий вариант — пересмотреть общий контракт и объявить абстракцию с более подходящим доменным checked-исключением. Это требует изменения клиентов и версионирования API, зато не связывает базовый интерфейс с деталями конкретного хранилища. Для публичной библиотеки обычно выбирают доменное исключение или явный результат операции, а не протаскивают технические исключения реализации.

Что кандидаты часто упускают

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

Да. Компилятор проверяет вызов по статическому типу ссылки, поэтому клиент видит исходный контракт базового метода — например, IOException. Фактически объект-наследник может выбросить только более узкий тип, но вызывающий код всё равно вправе обработать IOException; это сохраняет полиморфную совместимость.

Разрешено ли переопределению объявить более широкое unchecked-исключение?

Да. Если базовый метод не объявляет RuntimeException, наследник всё равно может явно указать RuntimeException или выбрасывать его без объявления. Компилятор не требует включать unchecked-исключения в контракт, но изменение ожидаемого поведения может быть несовместимым на уровне документации и практического использования API.

Как разрешается throws, если класс реализует два интерфейса с одинаковым методом, но разными checked-исключениями?

Реализация должна иметь набор checked-исключений, совместимый с обоими контрактами одновременно. Поэтому она может объявить только исключение, являющееся подтипом разрешённых типов обоих интерфейсов, либо не объявлять checked-исключения вообще. Если совместимого типа нет, часто приходится перехватывать исключения внутри реализации и преобразовывать их в общий доменный тип или менять дизайн интерфейсов.