Роман Аймалетдинов - Coroutines: боль обработки ошибок

Ближайшая конференция - Mobius 2024 Autumn, 11 октября (Online), 19-20 октября, Санкт-Петербург. Подробности и билеты: jrg.su/Yu6KNJ
- -
Спикер расскажет про проблемы, с которыми столкнется команда при затаскивании корутин в свой проект. Доклад сфокусирован на обработке ошибок - вы не услышите про то, что такое launch и async, но вспомните про try-catch. Узнаете про coroutineExceptionHandler и про то, как эти инструменты стреляют в ногу. Спикер расскажет, как по его мнению обезопасить себя от этих выстрелов.
Скачать презентацию: squidex.jugru.team/api/assets...

[@andreyliashuk2516]

Елизаров одобрил бы такой подход) Мы создали корутины чтобы убрать коллбеки, теперь давайте обвернем их в коллбеки.
У меня всегда возникает сразу вопрос, зачем вы стремитесь перехватить все ошибки? Почему код который потенциально может вернуть ошибку (например сетевой), нельзя обвернуть например в Result? Это заставит разработчика явно обработать ошибку и не добавляет бойлерплейт кода.
А перехватывать все ошибки это плохая идея, так как можно легко пропустить серьезные ошибки.

[@romanaymaletdinov5223]

Добрый день! И в ваших словах есть логика, однако я считаю, что больше вреда будет от необработанных ошибок и того, что разработчик не позаботился об error состоянии. С корутинами соблазн не обработать error невероятно велик. Ошибки же можно успешно выявлять с помощью логов аналитики и дебажных инструментов. Если мы хотим ронять апп время от времени, то перехваченные ошибки могут ронять апп на дебажных сборках и выключать фичи при фиксировании ошибок на сервере.
Как бы то ни было, оба подхода могут обеспечивать необходимое качество, вопрос в команде, ее особенностях, процессах фиксирования и выявления проблем. Если ваша команда опытна и давно пишет на корутинах - этот подход вам определенно не нужен.

[@quverr]

+1 за то что бы возвращать Result а потом fold'ить как в Arrow.

[@user-zh5il3gg6v]

Посмотрел только сейчас, и то, что меня терзало большую часть времени - так и сыграло. А именно 4:53 Роман подсвечивает ошибку, что мы ожидаем Exception, а функция mapServerResponse кидает Error. Но тут и у автора выходит ошибка: присмотритесь, мы не вызываем mapServerResponse, мы вызываем какой то loadSmth…
Я думал что эти функции вообще никак не связаны честно говоря, а в итоге - в первой вызывается вторая …

[@sweetcapitan5690]

Роман кололся, плакал, но продолжал есть кактус.

[@user-hv9ks6io5x]

А почему ни в одном примере не рассматривали SupervisorJob?

[@ilyavlasov7454]

Если немного упороться с infix функциями, то можно добиться такого кода:
launchMain {
// Run some suspend functions on Main
} catch {
// Handle error (it) on Main
}
или, если нужно обработать ошибку не на Main
launchMain {
// Run some suspend functions on Main
} catch on(Dispatchers.IO) {
// Handle error (it) on IO
}