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

Подписаться 11 тыс.

Просмотров 3,5 тыс.

50% 1

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

Наука

Опубликовано:

27 сен 2022

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 7

@andreyliashuk2516 Год назад

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

@romanaymaletdinov5223 Год назад

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

@quverr Год назад

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

@user-zh5il3gg6v 9 месяцев назад

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

@sweetcapitan5690 2 месяца назад

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

@user-hv9ks6io5x Год назад

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

@ilyavlasov7454 9 месяцев назад

Если немного упороться с 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 }