Что делает ключевое слово throws

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

🟢 Junior Level

Краткий ответ для собеседования (30 секунд)

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

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

Перехватить исключение на месте с помощью блока try-catch.
Продекларировать это же исключение (или его суперкласс) в своей собственной секции throws.

Разница между `throw` и `throws`

Ключевое слово	`throw`	`throws`
Где используется	Внутри тела метода или блока кода	В заголовке (сигнатуре) метода или конструктора
Роль	Оператор действия: немедленно создает и инициирует выброс объекта исключения	Элемент декларации: предупреждает о типах исключений, которые могут вылететь из метода
Синтаксис	`throw new IllegalArgumentException();`	`public void run() throws IOException;`
Аргумент	Конкретный экземпляр объекта (`Throwable`)	Список типов классов через запятую

Базовый пример на Java 21

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;

public class FileReaderService {

    // Декларируем, что метод может выбросить checked IOException
    public List<String> readLines(String filePath) throws IOException {
        return Files.readAllLines(Path.of(filePath));
    }

    // Вариант 1: Вызывающий код перехватывает ошибку локально
    public void processSafely(String path) {
        try {
            List<String> lines = readLines(path);
            System.out.println("Lines count: " + lines.size());
        } catch (IOException e) {
            System.err.println("Failed to read file: " + e.getMessage());
        }
    }

    // Вариант 2: Вызывающий код делегирует ответственность еще выше
    public void processAndPropagate(String path) throws IOException {
        List<String> lines = readLines(path);
        // дальнейшая обработка
    }
}

🟡 Middle Level

Правила переопределения методов и LSP (Liskov Substitution Principle)

При переопределении методов в подклассах или реализации интерфейсов правила полиморфизма в Java строго ограничивают секцию throws в соответствии с принципом подстановки Лисков:

public interface BaseRepository {
    void save() throws IOException;
}

public class SqlRepository implements BaseRepository {
    // 1. МОЖНО: сузить исключение до его подкласса (ковариантность исключений)
    @Override
    public void save() throws java.io.FileNotFoundException { }
}

public class MemoryRepository implements BaseRepository {
    // 2. МОЖНО: полностью убрать throws, если реализация не бросает проверяемых ошибок
    @Override
    public void save() { }
}

public class BadRepository implements BaseRepository {
    // 3. НЕЛЬЗЯ: добавить новое checked исключение или более широкий тип!
    // ОШИБКА КОМПИЛЯЦИИ: overridden method does not throw java.sql.SQLException
    // @Override
    // public void save() throws SQLException { }

    // 4. НЕЛЬЗЯ: расширить до супертипа!
    // ОШИБКА КОМПИЛЯЦИИ: Exception is not compatible with throws clause in BaseRepository
    // @Override
    // public void save() throws Exception { }
}

Почему так устроено: Клиент, вызывающий BaseRepository.save(), готов поймать только IOException. Если бы подкласс выбросил непродекларированный SQLException, блок catch (IOException e) пропустил бы ошибку, нарушив типобезопасность.

Unchecked исключения и `throws`

Синтаксис Java позволяет объявлять в throws непроверяемые исключения (RuntimeException и Error):

// Технически компилируется, но считается стилистической ошибкой
public void calculate(int val) throws IllegalArgumentException, NullPointerException {
    // ...
}

Практическое правило: Не указывайте unchecked-исключения в секции throws. Они не проверяются компилятором, загромождают сигнатуру метода и вводят разработчиков в заблуждение. Для документирования возможных рантайм-ошибок используйте тег Javadoc @throws IllegalArgumentException.

Байткод и JVM: Атрибут `Exceptions`

На уровне JVM виртуальная машина не проверяет соответствие throws в runtime. Информация о throws компилируется в .class-файл в специальный атрибут метода Exceptions:

// Результат декомпиляции javap -v FileReaderService.class:
public java.util.List<java.lang.String> readLines(java.lang.String) throws java.io.IOException;
  descriptor: (Ljava/lang/String;)Ljava/util/List;
  flags: (0x0001) ACC_PUBLIC
  Exceptions:
    throws java.io.IOException

Этот атрибут используется исключительно компилятором javac для проверки корректности клиентского кода. При вызове метода через Java Reflection (Method.invoke()) проверяемые исключения беспрепятственно вылетают наружу (будучи обернутыми в InvocationTargetException), доказывая, что рантайм HotSpot не валидирует вызовы по throws.

🔴 Senior Level

Тонкость конструкторов: исключения суперкласса

Поведение throws в конструкторах фундаментально отличается от методов:

public class Parent {
    public Parent() throws IOException {
        // Инициализация ресурса
    }
}

public class Child extends Parent {
    // Конструктор подкласса ОБЯЗАН объявить throws IOException (или более широкий тип)!
    // Он НЕ МОЖЕТ перехватить исключение конструктора суперкласса внутри своего тела!
    public Child() throws IOException, Exception {
        super(); // Первая строка конструктора обязана быть super()!
    }
}

В отличие от методов, конструктор подкласса не может убрать throws родителя, поскольку инструкция super(...) обязана быть первой строкой, и обернуть ее в try-catch синтаксически невозможно.

Обобщенные типы в исключениях (Generic Throws)

Java поддерживает параметризацию секции throws типом исключения. Это основа для создания универсальных функциональных адаптеров:

@FunctionalInterface
public interface ThrowingConsumer<T, E extends Throwable> {
    void accept(T t) throws E;
}

public class ExceptionAdapter {
    public static <T, E extends Throwable> void execute(T value, ThrowingConsumer<T, E> consumer) throws E {
        consumer.accept(value);
    }

    public static void demo() {
        try {
            // Тип E автоматически выводится компилятором как IOException
            execute("file.txt", path -> {
                throw new java.io.IOException("Disk read error");
            });
        } catch (java.io.IOException e) {
            System.out.println("Caught precisely inferred IOException!");
        }
    }
}

Ломающие изменения API (Binary & Source Compatibility)

В библиотечной разработке изменение сигнатуры throws является критическим событием:

Добавление нового checked-исключения: Ломает исходную совместимость (Source Compatibility). Любой клиентский проект перестанет компилироваться при обновлении версии библиотеки.
Удаление checked-исключения: Исходно и бинарно совместимо (старый клиентский блок try-catch продолжит работать, хотя компилятор может выдать предупреждение о мертвом перехвате).
Замена конкретного исключения на throws Exception: Антипаттерн “Throws Umbrella”, уничтожающий семантику API.

🎯 Шпаргалка для интервью

Вопросы для быстрой проверки

Можно ли в переопределенном методе подкласса убрать checked исключение, объявленное в базовом классе? Ответ: Да, можно. Подкласс имеет право сузить контракт исключений или вовсе не выбрасывать их. Это полностью соответствует принципу LSP (клиент, готовый к ошибке, просто никогда с ней не столкнется).
Может ли конструктор подкласса скрыть checked исключение, выбрасываемое конструктором суперкласса? Ответ: Нет, не может. Первой строкой любого конструктора обязан быть вызов super(...). Этот вызов невозможно обернуть в блок try-catch, поэтому конструктор подкласса обязан объявить в throws все checked-исключения конструктора родителя (или их супертипы).
Что произойдет, если вызвать метод с throws IOException через Reflection API (Method.invoke)? Ответ: Компилятор не потребует обязательного перехвата IOException. Если метод выбросит IOException, рефлексия обернет его в непроверяемое или проверяемое InvocationTargetException, демонстрируя, что проверка throws — это статический анализ javac.
Почему throws Exception в публичном интерфейсе считается плохой практикой? Ответ: Это размывает контракт API. Вызывающий код теряет информацию о реальных возможных отказах и вынужден писать неспецифичный перехват catch (Exception e), который непреднамеренно маскирует ошибки времени выполнения (NullPointerException, IllegalArgumentException).

Типичные ошибки и Red Flags

❌ Путаница между терминами throw и throws: Объяснение throws как «команды, которая выбрасывает ошибку в коде».
❌ Попытка объявить в методе подкласса новое checked исключение: Непонимание ограничений LSP и переопределения методов.
❌ Указание непроверяемых исключений (throws RuntimeException): Лишний визуальный шум, не дающий гарантий компилятора.
❌ Использование throws Exception в качестве “универсального решения”: Лишает архитектуру типизированной обработки ошибок.