```protected val scope = CoroutineScope(Supervisor...

# coroutines

[ursus]

protected val scope = CoroutineScope(SupervisorJob() + Dispatchers.Main)

fun pullToRefresh() {
    scope.launch {
        try {
           sync()
        } catch(ex: Exception) {
           // Never called <------------------
        }
    }
}


suspend fun sync() {
    supervisorScope { <-----------
        Log.d("Default", "a")
        launch {
            delay(200)
            if (true) error("") <---------------
            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]

SupervisorJob() at the top only handles direct children, so that's not relevant to this

[ephemient]

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]

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]

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]

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]

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

[ursus]

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

[ephemient]

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]

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

[ephemient]

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

[ephemient]

it propagates normally in that case

[ephemient]

if you want to collect all the errors while proceeding, then

val thrown = mutableListOf<Throwable>()
withContext(CoroutineExceptionHandler { _, t -> thrown.add(t) }) {
    supervisorScope {
        launch { error("a") }
        launch { error("b") }
    }
}

will handle them without additional work per child

[ursus]

Im a bit confused,

so if async propagates and therfore coroutineScope get canceled, but if it were to propagate then supervisorScope would crash,

[ursus]

so it is somehow special, that it doesnt make supervisorScope crash?

[ephemient]

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]

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]

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]

there is nothing particularly special about it

[ephemient]

normally, any exception cancels the whole job tree

[ursus]

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]

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

[ephemient]

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]

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

[ursus]

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]

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

[ursus]

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 😄 )

[ephemient]

sure, it's basically a scoped uncaught exception handler

[ephemient]

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

[ursus]

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

[ursus]

Okay I understand now, thank you!

[ephemient]

just to hopefully clear up some things I might have said ambiguously,

val scope = CoroutineScope(CoroutineExceptionHandler { _, ex -> 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]

whereas doing the same with

val scope = CoroutineScope(SupervisorJob() + CoroutineExceptionHandler { _, ex -> 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]

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

[Pablichjenkov]

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]

Or use flow where the catching is trivial

[gildor]

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]

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]

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]

Why would you need an exception handler for GlobalScope?

[ephemient]

not for GlobalScope, but for your own local GlobalScope substitute (e.g. something like viewModelScope on Android) it can be useful

[gildor]

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]

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]

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]

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]

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]

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