Rich Errors в Kotlin 2.4: шаг вперёд или шаг в сторону?

Команда Spring АйО не могла остаться в стороне и не прокомментировать одну из самых обсуждаемых новинок Kotlin, анонсированную на KotlinConf 2025 — Rich Errors. Вместо того чтобы выбрасывать исключения, теперь функции могут возвращать возможные ошибки как часть своей сигнатуры:

fun fetchUser(): User | NetworkError

Такой подход делает потенциальные сбои явными, упрощает тестирование и избавляет от try-catch для предсказуемых ошибок. Новинка уже доступна в Kotlin 2.4 и, по мнению авторов, особенно полезна в бизнес-логике.

Но в сообществе мнения разделились.

Что говорят сторонники Rich Errors?

• Это логичное продолжение идеи безопасности типов, как null safety.

• Ошибки становятся частью API — теперь явно видно, какие именно проблемы могут возникнуть.

• try-catch больше не нужен там, где ошибка — ожидаемый результат.

• Тестировать становится проще: вместо моков и исключений — обычная проверка значения.

• Хорошо сочетается с функциональными паттернами без необходимости подключать сторонние библиотеки.

Что вызывает сомнения?

• В контроллерах и сервисах с большим числом потенциальных ошибок сигнатуры методов становятся громоздкими.

• Нет способа элегантно агрегировать ошибки: A | B | C работает, но не имеет общей семантики.

• В рамках Spring-приложений реалистичная польза ограничена — фреймворки останутся на исключениях.

• Добавление такого типа обработки может серьёзно сказаться на времени компиляции.

И что теперь?

Для одних Rich Errors — это долгожданное улучшение и эволюция Kotlin. Для других — спорный эксперимент, который добавляет сложности без ощутимой пользы в реальных проектах.

А вы как думаете? Используете ли Rich Errors в своём коде — или пока просто наблюдаете со стороны?

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано