Елизаров одобрил бы такой подход) Мы создали корутины чтобы убрать коллбеки, теперь давайте обвернем их в коллбеки. У меня всегда возникает сразу вопрос, зачем вы стремитесь перехватить все ошибки? Почему код который потенциально может вернуть ошибку (например сетевой), нельзя обвернуть например в Result? Это заставит разработчика явно обработать ошибку и не добавляет бойлерплейт кода. А перехватывать все ошибки это плохая идея, так как можно легко пропустить серьезные ошибки.
Добрый день! И в ваших словах есть логика, однако я считаю, что больше вреда будет от необработанных ошибок и того, что разработчик не позаботился об error состоянии. С корутинами соблазн не обработать error невероятно велик. Ошибки же можно успешно выявлять с помощью логов аналитики и дебажных инструментов. Если мы хотим ронять апп время от времени, то перехваченные ошибки могут ронять апп на дебажных сборках и выключать фичи при фиксировании ошибок на сервере. Как бы то ни было, оба подхода могут обеспечивать необходимое качество, вопрос в команде, ее особенностях, процессах фиксирования и выявления проблем. Если ваша команда опытна и давно пишет на корутинах - этот подход вам определенно не нужен.
Посмотрел только сейчас, и то, что меня терзало большую часть времени - так и сыграло. А именно 4:53 Роман подсвечивает ошибку, что мы ожидаем Exception, а функция mapServerResponse кидает Error. Но тут и у автора выходит ошибка: присмотритесь, мы не вызываем mapServerResponse, мы вызываем какой то loadSmth… Я думал что эти функции вообще никак не связаны честно говоря, а в итоге - в первой вызывается вторая …
Если немного упороться с 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 }
Елизаров одобрил бы такой подход) Мы создали корутины чтобы убрать коллбеки, теперь давайте обвернем их в коллбеки.
У меня всегда возникает сразу вопрос, зачем вы стремитесь перехватить все ошибки? Почему код который потенциально может вернуть ошибку (например сетевой), нельзя обвернуть например в Result? Это заставит разработчика явно обработать ошибку и не добавляет бойлерплейт кода.
А перехватывать все ошибки это плохая идея, так как можно легко пропустить серьезные ошибки.
Добрый день! И в ваших словах есть логика, однако я считаю, что больше вреда будет от необработанных ошибок и того, что разработчик не позаботился об error состоянии. С корутинами соблазн не обработать error невероятно велик. Ошибки же можно успешно выявлять с помощью логов аналитики и дебажных инструментов. Если мы хотим ронять апп время от времени, то перехваченные ошибки могут ронять апп на дебажных сборках и выключать фичи при фиксировании ошибок на сервере.
Как бы то ни было, оба подхода могут обеспечивать необходимое качество, вопрос в команде, ее особенностях, процессах фиксирования и выявления проблем. Если ваша команда опытна и давно пишет на корутинах - этот подход вам определенно не нужен.
+1 за то что бы возвращать Result а потом fold'ить как в Arrow.
Посмотрел только сейчас, и то, что меня терзало большую часть времени - так и сыграло. А именно 4:53 Роман подсвечивает ошибку, что мы ожидаем Exception, а функция mapServerResponse кидает Error. Но тут и у автора выходит ошибка: присмотритесь, мы не вызываем mapServerResponse, мы вызываем какой то loadSmth…
Я думал что эти функции вообще никак не связаны честно говоря, а в итоге - в первой вызывается вторая …
Роман кололся, плакал, но продолжал есть кактус.
А почему ни в одном примере не рассматривали SupervisorJob?
Если немного упороться с 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
}