- Регистрация
- 23 Август 2023
- Сообщения
- 2 822
- Лучшие ответы
- 0
- Реакции
- 0
- Баллы
- 51
Offline
Команда Spring АйО не могла остаться в стороне и не прокомментировать одну из самых обсуждаемых новинок Kotlin, анонсированную на KotlinConf 2025 — Rich Errors. Вместо того чтобы выбрасывать исключения, теперь функции могут возвращать возможные ошибки как часть своей сигнатуры:
fun fetchUser(): User | NetworkError
Такой подход делает потенциальные сбои явными, упрощает тестирование и избавляет от try-catch для предсказуемых ошибок. Новинка уже доступна в Kotlin 2.4 и, по мнению авторов, особенно полезна в бизнес-логике.
Но в сообществе мнения разделились.
Что говорят сторонники Rich Errors?
Для одних Rich Errors — это долгожданное улучшение и эволюция Kotlin. Для других — спорный эксперимент, который добавляет сложности без ощутимой пользы в реальных проектах.
А вы как думаете? Используете ли Rich Errors в своём коде — или пока просто наблюдаете со стороны?
Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано
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 и всего, что с ним связано
