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

Компилятор анализирует верхнюю границу параметра типа в throws, а при вызове — выведенное или явно заданное значение этого параметра. Если возможный тип является проверяемым исключением, вызывающий код обязан его обработать или объявить дальше; если тип ограничен RuntimeException или Error, такое требование не возникает.

Параметр типа не отменяет проверку исключений: он делает её зависящей от конкретной специализации метода и контекста вызова.

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

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

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

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

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

Параметр типа в throws решает эту проблему, но создаёт важный вопрос: считать ли такой параметр проверяемым всегда или учитывать фактический тип, выбранный при вызове. Неверное понимание механизма приводит либо к лишним блокам обработки, либо к небезопасному обходу контроля checked exceptions.

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

Рассмотрим обобщённый метод:

static <E extends Exception> void rethrow(E error) throws E {
    throw error;
}

static void use() throws java.io.IOException {
    rethrow(new java.io.IOException());
}

При вызове аргумент IOException выводит E как IOException. Поэтому метод фактически рассматривается как выбрасывающий IOException, и вызывающий метод обязан обработать его или объявить в своей сигнатуре.

Если передать RuntimeException, параметр E будет соответствовать непроверяемому исключению. В этом случае обязательная обработка не требуется, поскольку RuntimeException является наследником RuntimeException, а исключения этого семейства не проверяются компилятором.

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

Ключевой механизм — вывод типа. Аргументы метода, явное указание параметра типа и целевой контекст могут определить конкретный тип E. После этого правила проверки исключений применяются к полученному типу, а не к абстрактному обозначению параметра.

Однако это не означает, что generic-метод способен безопасно превратить любое исключение в непроверяемое. Специальные конструкции вроде sneaky throw используют стирание типов и вывод RuntimeException, чтобы обойти проверку на стороне вызова. Они не меняют реальный объект исключения и могут ухудшить читаемость, диагностику и контракт API.

При стирании параметр типа E заменяется его первой границей. В примере с E extends Exception приведение к E во время выполнения фактически не проверяет конкретный тип E: JVM видит стёртую границу. Поэтому ответственность за корректность такого кода лежит на разработчике, а сигнатура метода должна честно отражать его поведение.

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

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

Вариант с параметром типа E extends Exception сохраняет конкретный тип исключения и позволяет компилятору требовать обработку только тогда, когда это действительно проверяемое исключение. Это предпочтительное решение, если тип исключения можно связать с аргументом или другим параметром метода.

Обход через sneaky throw уменьшает количество обязательных catch и иногда применяется во внутренних инфраструктурных библиотеках. Но он скрывает проверяемое исключение от сигнатуры вызывающего кода, поэтому для публичного API обычно хуже: ошибка обнаруживается позднее и не видна из контракта метода.

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

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

Всегда ли параметр типа в throws означает проверяемое исключение?

Нет. Проверка зависит от границ параметра и выведенного типа. Если параметр ограничен RuntimeException или Error, он относится к непроверяемым исключениям. Если граница допускает обычные checked exceptions, компилятор сохраняет требование обработки.

Меняет ли стирание типов реальный тип исключения?

Нет. Стирание меняет представление параметра типа в байткоде, но объект исключения сохраняет свой фактический класс. Если метод выбросил IOException, стирание не превращает её в Exception или RuntimeException; оно лишь ограничивает информацию, доступную в некоторых проверках компилятора и времени выполнения.

Почему sneaky throw не является доказательством безопасности generic-исключений?

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