image

Привет, Хабр!

Все любят runtime exceptions. Нет лучшего способа узнать о том, что что-то не было учтено при написании кода. Особенно — если исключения обваливают приложение у миллионов пользователей, и эта новость приходит паническим email'ом с портала аналитики. В субботу утром. Когда ты в загородной поездке.

После подобного всерьез задумываешься о обработке ошибок — и какие же возможности предоставляет нам Kotlin?

Первым на ум приходит try-catch. По мне — отличный вариант, но у него есть две проблемы:

  1. Это как-никак лишний код (вынужденная обертка вокруг кода, не лучшим образом сказывается на читаемости).
  2. Не всегда (особенно при использовании сторонних библиотек) из блока catch возможно получить информативное сообщение о том, что конкретно вызвало ошибку.

Давайте посмотрим во что try-catch превращает код при попытке решения вышеозвученных проблем.

Например, простейшая функция выполнения сетевого запроса 

fun makeRequest(request: RequestBody): List<ResponseData>? {
    val response = httpClient.newCall(request).execute()
    return if (response.isSuccessful) {
        val body = response.body()?.string()
        val json = ObjectMapper().readValue(body, MyCustomResponse::class.java)
        json?.data
    } else {
        null
    }
}

становится похожа на

fun makeRequest(request: RequestBody): List<ResponseData>? {
    try {
        val response = httpClient.newCall(request).execute()
        return if (response.isSuccessful) {
            val body = response.body()?.string()
            val json = ObjectMapper().readValue(body, MyCustomResponse::class.java)
            json?.data
        } else {
            null
        }
    } catch (e: Exception) {
        log.error("SON YOU DISSAPOINT: ", e.message)
        return null
    }
}

«Не так уж и плохо», может сказать кто-то, «вам с вашим котлином всё кодового сахарку хочется», добавит он (это цитата) — и будет… дважды прав. Нет, холиваров сегодня не будет — каждый решает за себя. Я лично правил код самописного json парсера, где парсинг каждого поля был завернут в try-catch, при этом каждый из блоков catch был пустым. Если кого-то устраивает подобное положение вещей — флаг в руки. Я же хочу предложить способ лучше.

В большинстве типизированных функционалых языках программирования предлагаются два класса для обработки ошибок и исключений: Try и Either. Try для обработки исключений, a Either для обработки ошибок бизнес логики.

Библиотека Arrow позволяет использовать эти абстракции вместе с Kotlin. Таким образом, можно переписать вышенаписанный запрос как следующий:

fun makeRequest(request: RequestBody): Try<List<ResponseData>> = Try {
    val response = httpClient.newCall(request).execute()
    if (response.isSuccessful) {
        val body = response.body()?.string()
        val json = ObjectMapper().readValue(body, MyCustomResponse::class.java)
        json?.data
    } else {
        emptyList()
    }
}

Чем этот подход отличается от использования try-catch?

Во-первых, любой кто будет читать этот код после тебя (а такие скорее всего будут) уже по сигнатуре сможет понять, что исполнение кода может привести к ошибке — и написать код её обработки. Тем более, что компайлер заругается, если это не будет сделано.

Во-вторых, появляется гибкость в том, как ошибка может быть обработана.

Внутри Try ошибка или успех исполнения представлены в виде классов Failure и Success соответственно. Если мы хотим, чтобы функция всегда что-то возвращала при ошибке, можно задать дефолтное значение:

makeRequest(request).getOrElse { emptyList() }

Если требуется обработка ошибики посложнее, на помощь приходит fold:

makeRequest(request).fold(
    {ex ->
        // делаем что-то с ошибкой и возвращаем дефолтное значение
        emptyList()
    },
    { data -> /* используем полученные данные */ }
)

Можно воспользоваться функцией recover — ее содержимое будет полностью проигнорировано, если Try вернет Success.

makeRequest(request).recover { emptyList() }

Можно исопользовать for comprehensions (позаимствованные создателями Arrow из Scala), если требуется обработка результата Success с помощью последовательности команд, путем вызова фабрики .monad() на Try:

Try.monad().binding {
    val r = httpclient.makeRequest(request)
    val data = r.recoverWith { Try.pure(emptyList()) }.bind()
    val result: MutableList<Data> = data.toMutableList()
    result.add(Data())
    yields(result)
}

Вариант выше можно написать без использования binding, но тогда он будет по-другому читаться:

httpcilent.makeRequest(request)
    .recoverWith { Try.pure(emptyList()) }
    .flatMap { data ->
    	val result: MutableList<Data> = data.toMutableList()
        result.add(Data())
        Try.pure(result)
    }

В конце концов, результат функции можно обработать с помощью when:

when(response) {
    is Try.Success -> response.data.toString()
    is Try.Failure -> response.exception.message
}

Таким образом с помощью Arrow можно заменить далеко не идеальную конструкцию try-catch на что-то гибкое и очень удобное. Дополонительным плюсом использования Arrow является то, что не смотря на то, что библиотека позиционирует себя как функциональная — отдельные абстракции оттуда (например, тот же Try) можно использовать, продолжая писать старый добрый ООП код. Но предупреждаю — может понравиться и втянетесь, через пару недель начнете изучать Haskell, а ваши коллеги очень скоро перестанут понимать ваши рассуждения о структуре кода.

P.S.: Оно того стоит:)