```protected val scope = CoroutineScope SupervisorJob + Disp

Question

```protected val scope = CoroutineScope SupervisorJob + Dispatchers Main fun pullToRefresh scope launch try sync catch ex Exception Never called lt suspend fun sync supervisorScope lt Log d Default a launch delay 200 if true error lt Log d Default b launch delay 300 Log d Default c ``` Why does `supervisorScope` crash the app on android I want to run two syncs in parallel inside `sync` and I don t want ones exception to cancale the other so `supervisorScoped` seemed what I want but it crashes the app with ```2023 02 03 02 11 55 860 foo bar E AndroidRuntime FATAL EXCEPTION main java lang IllegalStateException at foo bar DashboardViewModel$pullToRefresh$1$1$1 invokeSuspend DashboardViewModel kt 323 at kotlin coroutines jvm internal BaseContinuationImpl resumeWith ContinuationImpl kt 33 Suppressed kotlinx coroutines DiagnosticCoroutineContextException StandaloneCoroutine Cancelling ebf2ef7 Dispatchers Main immediate ``` Can t even catch it as if it were a `Error` not a `Exception`

ephemient · Answer

`SupervisorJob ` at the top only handles direct children so that s not relevant to this

ephemient · Answer

the `catch` can only run after `sync` completes so it would either have to stop as soon as `error ` happens which happens in the non `supervisorScope` case or exceptions have to go unhandled by this structure which is what happens here when the unhandled exception reaches the top level you get the crash

ephemient · Answer

if there s a `CoroutineExceptionHandler` in context somewhere it can handle the exceptions asynchronously or if you use `async` instead of `launch` inside of `supervisorScope` that will also capture the exception

Pablichjenkov · Answer

Something like the supervisorScope doesn t report the exception through the continuation which is what try expects It levels the exception up to it s parent scope

ursus · Answer

I see so it doesnt pass the exception to the next suspend function because it would have to then resume multiple times which would break the contract

ursus · Answer

but rather side effects the exception but since android has no default handler it crashes

ursus · Answer

soo should I just go back to `coroutineScope` and try catch inside the `launch`es

ephemient · Answer

as I mentioned `async` will handle the exception so ```supervisorScope async error a async error b ``` ignores the errors of course you can also add completion handlers if you want

ursus · Answer

hm but async doesnt propagate the error right therefore I might as well use coroutineScope+async

ephemient · Answer

no `coroutineScope` will be cancelled when an exception happens even inside an `async`

ephemient · Answer

it propagates normally in that case

ephemient · Answer

if you want to collect all the errors while proceeding then ```val thrown = mutableListOf lt Throwable gt withContext CoroutineExceptionHandler t gt thrown add t supervisorScope launch error a launch error b ``` will handle them without additional work per child

ursus · Answer

Im a bit confused so if async propagates and therfore coroutineScope get canceled but if it were to propagate then supervisorScope would crash

ursus · Answer

so it is somehow special that it doesnt make supervisorScope crash

ephemient · Answer

when there is a `throw` inside `async` inside a `coroutineScope` or almost any other scope for that matter it cancels the parent which cancels other children and is propagated as normal

ephemient · Answer

when there is a `throw` inside `async` inside `supervisorScope` `supervisorScope` doesn t do anything with it so it simply completes the `Deferred` with the exception

ursus · Answer

so there is special handling of Deffered I see I wasnt getting why would async work over launch I though supervisor just swallows exceptions no matter what kind of coroutine produced it

ephemient · Answer

there is nothing particularly special about it

ephemient · Answer

normally any exception cancels the whole job tree

ursus · Answer

okay so because async handled exceptions differntly in general and If I were to have exception handler setup it would behave the same way

ursus · Answer

so Im basically failing just because not having logger setup with the launches

ephemient · Answer

but because `supervisorScope` ignores failures of its children `async` gets to capture the exception without being cancelled `launch` doesn t have any way to capture the exception and it can t be returned via the usual means because that would require `supervisorScope` to handle it so it gets passed up the parent scopes

ephemient · Answer

didn t I give an example of having a handler just above

ursus · Answer

yes you did I m trying to understand so there wasn t nothing particularly wrong with my mental model just a logger was uninitialized and thats the whole issue i e a no op non null exc handler would make it all work as expected

ephemient · Answer

inside a normal `coroutineScope` the `CoroutineExceptionHandler` isn t useful because it ll cancel the tree first

ursus · Answer

okay so the handler is not just a simple interface where to report exceptions to the way thread uncaught handler is alteast I think it is smile

ephemient · Answer

sure it s basically a scoped uncaught exception handler

ephemient · Answer

where normal cancellation counts as being handled so that doesn t go through it

ursus · Answer

I see so thr issue is the children get canceled anyways with coroutineScope not inside the handler or whatever was I thinking

ursus · Answer

Okay I understand now thank you

ephemient · Answer

just to hopefully clear up some things I might have said ambiguously ```val scope = CoroutineScope CoroutineExceptionHandler ex gt println caught $ex scope launch error scope launch delay 100 println ``` in this example ` ` gets printed by the handler because there s no parent but ` ` doesn t get printed because the `scope` s own `Job` becomes cancelled if you don t specify a `Job` when creating a scope it ll add one itself

ephemient · Answer

whereas doing the same with ```val scope = CoroutineScope SupervisorJob + CoroutineExceptionHandler ex gt println caught $ex ``` will result in ` ` printed by the handler and ` ` printed normally because the `SupervisorJob` doesn t cancel when its children fail same as the `supervisorScope` case

ursus · Answer

Yes I was basically looking for what I needed to add to make supervisorScope+launch work besides the async alternative

Pablichjenkov · Answer

As a rule of thumb I try to avoid my code logic depending on the exception propagation logic of the coroutine cluster I rather try catch or runCatching in the suspicious scope and convert the exception into an error domain value

Pablichjenkov · Answer

Or use flow where the catching is trivial

gildor · Answer

Totally with < Pablichjenkov> here We have 0 cases of exception handler usage in the project and never regret it Handle exceptions in the code which runs coroutine use simple try catch everywhere

gildor · Answer

Essentially for you example I would remove supervisorScope from sync and handle exception on level of each launch or just wrap coroutineScope of sync with try catch

ephemient · Answer

I don t completely agree yes often you don t need an exception handler but if you re creating local `GlobalScope` substitute `SupervisorJob + CoroutineExceptionHandler` is what you need

gildor · Answer

Why would you need an exception handler for GlobalScope

ephemient · Answer

not for `GlobalScope` but for your own local `GlobalScope` substitute e g something like `viewModelScope` on Android it can be useful

gildor · Answer

Yes I got it why would you need it for viewModel If it used by VM why not handle all errors there explicitly instead of relying on error handler

ephemient · Answer

because sometimes you can t suppose you re writing a server framework and you want to have a coroutine scope per child but unhandled exceptions from one request should not crash the whole process then you need an exception handler scoped `try` `catch` doesn t cover everything for reasons discussed above

gildor · Answer

Yep I totally see some cases like server framework this why I asked about view model which same as example from original message is UI related But even for server framework I would probably instead use something like this mySercerScope launch val endpoint = resolveEndpoint val responce = try coroutineScope endpoint process request catch e processEndpointException endpoint e So no custom error handlers which also can escape it It doesn t mean that there are no use cases just that I believe those cases are much more rare

gildor · Answer

I m not against the whole idea of error handlers there are for sure some use cases but I believe that all cases which I see in this channel are better to handle different ways and not rely on error handler at all

ephemient · Answer

I brought up `viewModelScope` as possibly the best known example of a scope that is global to a certain lifetime that is shorter than the whole process

ephemient · Answer

but did you read up thread that `try` `catch` will not catch everything that s literally where we started this conversation from