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

Стандартные функциональные интерфейсы Stream API из пакета java.util.function не объявляют проверяемые исключения в сигнатурах своих абстрактных методов. Поэтому лямбда, совместимая, например, с Function или Predicate, обязана обработать проверяемое исключение внутри себя либо преобразовать его в непроверяемое.

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

В Java 8 лямбды и функциональные интерфейсы добавили способ передавать поведение в методы, включая операции Stream. Стандартные интерфейсы были спроектированы с простыми сигнатурами методов без throws, чтобы одинаково использовать их в большом числе операций и не заставлять каждый Stream-метод распространять сведения о возможных исключениях.

Это решение упростило API, но создало неудобство при вызове методов ввода-вывода, парсинга и других операций, которые объявляют проверяемые исключения.

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

Метод Stream принимает конкретный функциональный интерфейс, например Function<T, R>. Его метод apply не допускает проверяемое исключение в контракте, поэтому вызов метода, объявляющего такое исключение, внутри лямбды не компилируется без обработки.

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

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

Компилятор проверяет совместимость тела лямбды с методом целевого функционального интерфейса. У Function<T, R> метод R apply(T value) не объявляет проверяемых исключений, поэтому тело лямбды не может выбросить, например, IOException наружу напрямую.

Обычно применяют один из вариантов:

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

List<String> names = paths.stream()
    .map(path -> {
        try {
            return Files.readString(path);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    })
    .toList();

Здесь map принимает Function, а UncheckedIOException позволяет прервать выполнение конвейера. Терминальная операция или внешний код может перехватить это исключение и извлечь исходный IOException через причину.

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

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

Сервис читает множество конфигурационных файлов и преобразует их содержимое в объекты. Рассматривались три варианта: вернуть null при ошибке, обработать исключение внутри лямбды и пропустить файл либо обернуть ошибку в UncheckedIOException.

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

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

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

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

Ответ: Нет, у лямбда-выражения нет самостоятельной сигнатуры, которую можно дополнить throws. Его допустимые исключения определяются абстрактным методом целевого функционального интерфейса. Если интерфейс объявляет throws, лямбда может выбрасывать совместимые исключения; у стандартного Function такого объявления нет.
Вопрос: Почему обёртка в RuntimeException не делает исключение проверяемым для Stream API?

Ответ: Проверка выполняется на этапе компиляции по типу исключения, которое выбрасывает тело лямбды. После преобразования в RuntimeException исключение становится непроверяемым, поэтому оно совместимо с Function, но компилятор больше не требует его обработки. При этом исходная причина не исчезает, если передать её конструктору обёртки.
Вопрос: Почему собственный функциональный интерфейс с throws не заменяет стандартный интерфейс во всех операциях Stream?

Ответ: Методы Stream объявлены с конкретными типами параметров, например Function, Consumer или Predicate. Интерфейс с таким же количеством параметров, но другим именем не является подтипом соответствующего стандартного интерфейса, поэтому напрямую передать его в map, forEach или filter нельзя. Нужен адаптер, который перехватывает проверяемое исключение и выбирает стратегию его преобразования или обработки.