На KotlinConf 2025 анонсировали одну из самых обсуждаемых новинок Kotlin — 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 АйО 🫣