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

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

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

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

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

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

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

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

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

При компиляции throws используется главным образом для контроля проверяемых исключений. Для RuntimeException, Error и их подклассов компилятор не требует ни catch, ни объявления throws.

Во время выполнения JVM не сверяет фактически выброшенный объект с перечнем типов в throws. Исключение передаётся вверх по стеку, а каждый обработчик проверяется по фактическому типу объекта: обработчик подходит, если его тип является супертипом выброшенного исключения.

Например, IllegalArgumentException является подклассом RuntimeException, поэтому его можно перехватить явно. Обработчик Exception тоже подходит, поскольку RuntimeException наследуется от Exception, но такой обработчик может скрыть разные причины сбоя и требует осторожного применения.

class Service {
    static void validate(int value) {
        if (value < 0) {
            throw new IllegalArgumentException("negative value");
        }
    }

    public static void main(String[] args) {
        try {
            validate(-1);
        } catch (RuntimeException e) {
            System.out.println(e.getMessage());
        }
    }
}

Метод validate не обязан объявлять throws IllegalArgumentException, но исключение реально возникает и перехватывается вызывающим кодом. Это не означает, что throws бесполезен: для проверяемых исключений он остаётся частью контракта и влияет на компиляцию вызывающего кода.

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

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

Сервис принимает идентификатор заказа. Вариант с catch (Exception) на границе каждого метода формально перехватывает и проверяемые, и непроверяемые исключения, но смешивает ожидаемые ошибки с дефектами и усложняет диагностику.

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

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

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

Вопрос: Может ли метод объявить throws RuntimeException, и изменит ли это требования к вызывающему коду?

Ответ: Да, объявить его можно, но это не сделает исключение проверяемым. Вызывающий код по-прежнему не обязан добавлять catch или собственное объявление throws. Такое объявление может служить документацией, однако компилятор не будет принуждать к обработке.
Вопрос: Перехватит ли catch (RuntimeException) проверяемое исключение, если оно было обёрнуто в RuntimeException?

Ответ: Да, потому что обработчик анализирует тип внешнего объекта, фактически выброшенного из блока. Исходное проверяемое исключение в этом случае находится в cause и само по себе не участвует в выборе обработчика. Если исходная причина важна для диагностики, её следует сохранить при создании оболочки и затем корректно журналировать.
Вопрос: Что произойдёт, если метод без throws выбросит непроверяемое исключение, а вызывающий код его не перехватит?

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