Команда 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 и всего, что с ним связано
