➕ Почему в Kotlin никогда не будет полноценных Union-типов?

В среду мы готовим полноценный ролик с разбором новой фишки Kotlin – Rich Errors a.k.a. Union-типы для ошибок (если вы из будущего, где ролик уже выложен, то обязательно гляньте!).

Я зарисовал на картинке минимальный пример с демонстрацией новой фичи для работы с ошибками. И да, эта фича вообще никак не связана с исключениями. Слева в типе указывается успешный результат, справа – все виды ошибок, которые могут произойти. Подобно тому, как работает Result в Rust, Either в Haskell, Ocaml, Scala, Error Union Type в Zig и error в Go.

Читайте ниже про новый синтаксис.

📥 Мы включили возможность писать личные сообщения в этот канал

Старая добрая предложка из ВКонтакте появилась в новой версии Telegram. Обновляйте ваши клиенты, и смотрите на кнопочку внизу экрана.

А чтобы пообщаться с сообществом, вступайте в @kotlinmetachat. Я и Эмиль будем отвечать в обоих чатах.

📹 Запись второго стрима: JetBrains переизобрели checked exceptions? Смотрим на Rich Errors и почему в Kotlin не будет полноценных Union-типов.

Посмотрели как к этому вообще пришли, какие есть альтернативы в других экосистемах и почему не хотят реализовывать полноценные Union-типы в Kotlin. Разобрали proposal-ы с обсуждением разработчиков из JetBrains про Union-типы в Kotlin.

И, главное, поняли чем они могут быть лучше sealed interfaces, Result-типов и checked exceptions.

YouTube

💥 return делай, throw не делай

Что же, какое-то длиннопостное настроение на этой неделе. Сегодня поговорим про исключения. Когда их использовать нужно, и когда их использовать не нужно. Идеалом для меня по этой теме был и есть этот пост от Романа Елизарова на Medium.

Крайне советую с ним ознакомиться, сохранить в закладки, и пересылать всем, кто не следует конвенциям, описанным там. И не просто потому что так сказал Роман Елизаров, а потому что в посте очень доходчиво описаны причины таких конвенций. Их же я опишу в следующих постах.

☕️ Java и Checked Exceptions

Этот уникальный концепт появился в Java для работы с исключениями. С одной стороны – мы получаем возможность не делать проверок на if, а с другой стороны – компилятор проверит, что где-нибудь мы обязательно обработаем неудачный сценарий.

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

По итогу, начиная с 2010 года, в рекомендациях к хорошему года на Java стал фигурировать отказ от Checked Exceptions. А добивающим был выход Java-лямбд, который окончательно похоронил Checked-Exceptions.

🏝 Исключения в Kotlin

Kotlin унаследовал концепт исключений из Java и они поддерживаются из коробки для удобной работы с Java API. Но как и другие JVM-языки, Kotlin решил не перенимать Checked Exceptions. До Kotlin 2.4.

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

❗️ Согласно конвенции, вы не должны отлавливать исключения в обычном Kotlin коде. Это считается плохой практикой. Отлов исключений должен происходить в библиотечном коде, либо в небольшом количестве функций, созданных под каждый сценарий, где потенциально может понадобиться обработать исключение.

🔐 Безопасное API

Основной сценарий использования исключений в Kotlin – логические ошибки (далее – нарушение контракта). Если в какой-то момент программа попала в состояние, в котором она не должна оказаться, то выкидывается исключение.

Часто для этого используются функции check(), require() и error(). Доку тут я пересказывать не буду, про отличия можете почитать сами.

В случае, если возникла ошибка, которую необходимо обработать, – не нужно использовать исключения. Используйте nullable-типы или sealed interface.

❗️ Вы должны проектировать свои API следующим образом: используйте исключения как индикатор нарушения контракта, типобезопасные результаты для всего остального. Не используйте исключения как ожидаемый результат выполнения функции.

Иногда, правда, заранее неизвестно, является ли определённая ошибка нарушением контракта или той, которую необходимо обработать. В таком случае предлагается делать 2 варианта для функции, как это делает стандартная библиотека Kotlin:

• fun String.toInt(): Int, если отличный от Int ввод является нарушением контракта

• fun String.toIntOrNull(): Int?, если необходимо обработать сценарий некорректного ввода

🌐 IOException

Ох, это самое интересное, и самое спорное. IOException – точно не является нарушением контракта, но IOException любят и в JetBrains. Так, например, даже в новых библиотеках, написанных с нуля (имею ввиду ktor), активно используются эти исключения. Т.е. для таких исключений делается исключение (pun intended).

Аргументация такова: если бы после каждого IO-вызова нужно было бы проверять была ли выполнена операция успешно, то у нас было бы много бойлерплейта. Поэтому на IO-запросы нужен единый для всего приложения паттерн для обработки исключений. Обычно это делается на границе между низкоуровневой сетевой логикой и высокоуровневой доменной логикой. Для меня эта граница находится в репозитории (в архитектурном смысле). Все классы-репозитории возвращают kotlin.Result и не имеют права кидать никаких исключений.

То, чего нет в статье Романа, но лично я предпочитаю для пущей явности: все функции, которые потенциально кидают IOException, я помечаю суффиксом OrThrow(). Таким образом, я всегда вижу функции, которые могут выкинуть исключение IOException, и каждый раз при их вызове мне не нужно лезть в документацию или помнить, кидает ли конкретная функция исключение.