Как вы, возможно, знаете, я против использования исключений для возврата бизнес-значений. Этот подход популярен в сообществе, и часто для сохранения подробностей об ошибке используют sealed-иерархии.
Фича, о которой я расскажу вам сегодня, не новая, но одна из моих любимых за последнее время. Она есть в других языках, но у нас она появилась относительно недавно, под экспериментальным флагом в Kotlin 2.2. Context Sensitive Resolution позволяет не писать полный путь до класса, если его можно понять из контекста. Пример этой фичи есть на картинке прикреплённой к посту. Полный список мест, где работает эта фича:
• Выражения внутри
when
• При возврате после
return
• Переменные, у которых объявлен тип
• Проверки на тип (
as
, is
)• Параметры функций
Казалось бы - у нас есть импорты, можно же просто импортнуть
Success
, но не всё так просто. Если мы имеем дело с несколькими типами, который называются Success
, импортнуть их 2 раза не выйдет - будет конфлит импортов. А с этой фичей даже импорт не нужен. А бонусом идет более хорошая поддержка в IDE. Когда я делал аналоги DSL на Swift, я всегда кайфовал от того, как удобно там работает эта фича. Нет загрязнения неймспейса, но и много буков писать не надо. Все в плюсе!Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🍌2 2❤🔥1👍1
Запустили с Эмилем тестовый стрим и поняли, что интернет-соединение вообще не вывозит. Сегодняшний стрим отменяется ввиду того, что я заспаунился в деревне с такими провайдерами (контора солнышек). Переносим его на долго, также как и следующие стримы: ориентировочно на 23 августа.
А пока – наслаждаемся летом и новостями о Kotlin в текстовом формате. Всем спасибо, что поддерживаете наш канал, он развивается благодаря вам
Please open Telegram to view this post
VIEW IN TELEGRAM
😨15😭10 8🌚4
runSuspendCatching
Ещё несколько лет назад появился issue к репозиторию kotlinx.coroutines с предложением о создании функции, которая должна работать также, как runCatching, но при этом введя дополнительную логику работы с CancellationException.
runCatching из stdlib по умолчанию обрабатывает все возможные исключения, которые попадают в блок. Но это нарушает принципы structured concurrency: отмена корутин работает засчёт выбрасывания CancellationException: он должен игнорироваться обработчиками исключений, чтобы можно было корректно совершать отмену.
В дискуссии под issue довольно много размышлений о целесообразности введения такой функции в библиотеку, а пока многие люди реализуют её в своих проектах сами
Ещё несколько лет назад появился issue к репозиторию kotlinx.coroutines с предложением о создании функции, которая должна работать также, как runCatching, но при этом введя дополнительную логику работы с CancellationException.
runCatching из stdlib по умолчанию обрабатывает все возможные исключения, которые попадают в блок. Но это нарушает принципы structured concurrency: отмена корутин работает засчёт выбрасывания CancellationException: он должен игнорироваться обработчиками исключений, чтобы можно было корректно совершать отмену.
В дискуссии под issue довольно много размышлений о целесообразности введения такой функции в библиотеку, а пока многие люди реализуют её в своих проектах сами
3 7👍4 1