Если имеется в виду поведение которое описано в Мифе 2, то тут как бы дается гибкость и вариативность поведения.
Иногда может нужно отменить скоуп не дожидаясь await. Например мы в async идет в базу получить строку что бы найти ее в файлах на диске. Т.е. в начале мы делаем async, потом читает 10 файлов, а потом через await берем строку и ищем ее в файлах. В этом случае если это все сделаем в coroutineScope, то он перестанет читать как только async завершится с исключением.
Пример придуманный, но наверно если какие то похожие случаи которые в реальной жизни есть.
У меня была такая же ситуация, поэтому и появилась эта статья)
В ней я пытался донести что на самом деле обработка ошибок не сложная, а умещается в одно правило по отношению к корутинам «СРАЗУ распространяют ошибку. ЕСЛИ ее не может обработать родитель, делают это сами».
Самому когда раньше читал статьи на эту тему не хватало общего правила, т.к. чаще всего дело ограничивалось частными примерами без выявления общего правила.
Если я правильно понял под взаимовлиянием имеется в виду что одна корутина может быть родителем другой. А какая логика происходит если дочерняя или родительская корутина бросила исключение как раз описана в текущей статье.
Да, но в нативных потоках задачи берут себе полностью забирают поток на время исполнения, а в корутинах пока задаче поток не нужен, поток будет выполнять другую задачу.
В примере который я скинул можно заменить newSingleThreadExecutor на newCachedThreadPool и он отработает примерно за тоже время что и корутины, но тогда в пуле будет создано 3 потока, когда корутинам будет достаточно одного
Плюс еще для android google продвигает корутины как рекомендуемый подход для асинхронной работы и рынок чаще выбирает корутины, т.к. больше людей при изучении android учат корутины чем rxJava и нативные JVM потоки.
Если имеется в виду поведение которое описано в Мифе 2, то тут как бы дается гибкость и вариативность поведения.
Иногда может нужно отменить скоуп не дожидаясь await. Например мы в async идет в базу получить строку что бы найти ее в файлах на диске. Т.е. в начале мы делаем async, потом читает 10 файлов, а потом через await берем строку и ищем ее в файлах. В этом случае если это все сделаем в coroutineScope, то он перестанет читать как только async завершится с исключением.
Пример придуманный, но наверно если какие то похожие случаи которые в реальной жизни есть.
У меня была такая же ситуация, поэтому и появилась эта статья)
В ней я пытался донести что на самом деле обработка ошибок не сложная, а умещается в одно правило по отношению к корутинам «СРАЗУ распространяют ошибку. ЕСЛИ ее не может обработать родитель, делают это сами».
Самому когда раньше читал статьи на эту тему не хватало общего правила, т.к. чаще всего дело ограничивалось частными примерами без выявления общего правила.
Если я правильно понял под взаимовлиянием имеется в виду что одна корутина может быть родителем другой. А какая логика происходит если дочерняя или родительская корутина бросила исключение как раз описана в текущей статье.
Да, но в нативных потоках задачи берут себе полностью забирают поток на время исполнения, а в корутинах пока задаче поток не нужен, поток будет выполнять другую задачу.
В примере который я скинул можно заменить newSingleThreadExecutor на newCachedThreadPool и он отработает примерно за тоже время что и корутины, но тогда в пуле будет создано 3 потока, когда корутинам будет достаточно одного
Да, она была бы хороша для текущей статьи в плане введения в различные виды job и корутин билдеры. Т.к. там довольно подробно описаны их поведения.
Как пример https://pl.kotl.in/Ha6iriRGk
Плюс еще для android google продвигает корутины как рекомендуемый подход для асинхронной работы и рынок чаще выбирает корутины, т.к. больше людей при изучении android учат корутины чем rxJava и нативные JVM потоки.