Rich Errors в Kotlin 2.4 — революционное изменение в обработке ошибок

Один анонс на KotlinConf 2025 особенно привлек внимание Android-разработчиков (включая меня). На сцене Михаил Зареченский представил нечто, что может кардинально изменить подход к обработке ошибок в Kotlin — Rich Errors, которые теперь официально появятся в Kotlin 2.4.

Почему это важно

Если вы уже давно пишете на Kotlin, то знаете, насколько этот язык ценит явность, например, null safety, smart casting, sealed классы. Однако обработка ошибок всегда отставала. Мы полагались на try-catch, Result или сторонние библиотеки, такие как Either от Arrow. Конечно, это работало, но всегда казалось немного неуклюжим по сравнению с остальной элегантностью Kotlin.

С Rich Errors все это скоро изменится.

Что такое Rich Errors

По сути, Rich Errors переворачивают сценарий: вместо того, чтобы генерировать исключения, функции теперь могут возвращать их как часть системы типов.

Вот простой пример:

fun fetchUser(): User | NetworkError

Этот оператор | реален — это не опечатка. Он сообщает компилятору, что fetchUser() может вернуть либо User, либо NetworkError. Другими словами, возможные состояния сбоя теперь явно закодированы в сигнатуре функции.

Это очень важно. Я вижу три огромных преимущества этого подхода:

1. Типобезопасность в основе

Вам больше не нужно гадать, что может пойти не так. Компилятор знает пути сбоев — и заставляет вас обрабатывать их. Больше никаких «ой, я забыл поймать это пограничное исключение».

2. Больше никаких шаблонных try-catch

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

3. Гораздо проще тестировать

Раньше тестирование ошибок означало настройку моков для генерации исключений. А теперь? Вы просто проверяете возвращаемые значения. Просто и понятно.

Пример из реальной жизни: до и после

Позвольте мне показать вам, как это меняет наш код.

Старый способ (try-catch):

fun loadUserData() {
    try {
        val user = fetchUserLegacy()
        show(user)
    } catch (e: NetworkError) {
        showError("Try again later, network issue.")
    } catch (e: AnotherException) {
        showError("Something else went wrong.")
    }
}

Способ с Rich Error:

fun fetchUser(): User | AppError {
    if (/* network fails */ false) return NetworkError(503)
    if (/* user not found */ false) return UserNotFoundError
    return User("123", "Ada")
}

fun loadUserDataNew() {
    val result = fetchUser()
    when (result) {
        is User -> show(result)
        is NetworkError -> showError("Network issue (${result.code}). Try again.")
        is UserNotFoundError -> showError("User not found. Please check your credentials.")
    }
}

Заметили, чего не хватает? Да — нет try-catch, и тем не менее все пути ошибок обрабатываются четко и явно.

За пределами сетевых вызовов: где это особенно полезно

Rich Errors подходят не только для HTTP-запросов. Они идеально подходят для:

• Проверки ввода
  fun validateEmail(email: String): ValidEmail | EmailValidationError
• Операций с файлами
  fun readFile(path: String): FileContent | FileAccessError
• Авторизации
  fun login(credentials: Credentials): Session | AuthFailure

Везде, где ожидается сбой, Rich Errors может вмешаться и сделать ваш код более безопасным и предсказуемым.

Это очень похоже на Kotlin

Kotlin всегда был ориентирован на ясность и безопасность типов. Так же, как nullable типы сделали проблемы с null частью системы типов, Rich Errors переносят операционные сбои в ту же область.

Михаил Зареченский подчеркнул, что речь идет о том, чтобы помочь разработчикам писать надежный, ясный и поддерживаемый код. И, честно говоря, я думаю, что он прав.

Заключительные мысли

Это одно из самых интересных дополнений к Kotlin, которое я видел за последние годы. Оно способствует изменению мышления: не относитесь к ошибкам как к неожиданностям — относитесь к ним как к ожидаемым возможностям.

Я с нетерпением жду возможности попробовать это (особенно в блоках try-catch, похожих на спагетти). Если вы работаете над чем-либо на основе Kotlin, особенно над Android-приложениями, вам стоит обратить на это внимание.

Что вы думаете? Будете ли вы использовать Rich Errors в своем следующем проекте на Kotlin? Давайте обсудим.

Источник