dimsuz
11/16/2021, 4:58 PMsupervisorScope
in which I want to do mutliple launch
-es and allow each one to fail individually without cancelling other running ones. At the same time I'd want to install an exception handler on the supervisorScope
itself to centrally handle everyting.
But it seems that this can't be done, according to official documentation, i'll need to do launch(handler)
every time. Do I understand this right?
It's not problematic, but I'd rather avoid "forgetting" to pass "handler" to launch
and have it automatically provided...Joffrey
11/16/2021, 5:23 PMsupervisorScope
function, but you could define your supervisor scope manually like CoroutineScope(SupervisorJob() + handler)
and then run your coroutines inside and cancel it when appropriate. It's not ideal but it does the job (pun intended)Casey Brooks
11/16/2021, 5:23 PMsupervisorScope{}
function, you can build a coroutineScope
that includes both your exception handler and a SupervisorJob
. Something like this might help:
val newScope = originalCoroutineScope +
uncaughtExceptionHandler +
SupervisorJob(parent = originalCoroutineScope.coroutineContext[Job])
newScope.launch {
// ...
}
newScope.launch {
// ...
}
Joffrey
11/16/2021, 5:24 PMcoroutineScope
and supervisorScope
don't provide a way to override the context 🤔Casey Brooks
11/16/2021, 5:25 PMsupervisorScope
, it looks like basically creates a new, completely isolated coroutine, unlike withContext
and similar functions which augment the current coroutine.coroutineScope
and supervisorScope
is to allow its children to fail without cancelling the entire coroutine. It is isolated from its parent so that you can manually control what happens when its children failJoffrey
11/16/2021, 5:37 PMthe purpose of bothThis is only applicable toandcoroutineScope
is to allow its children to fail without cancelling the entire coroutinesupervisorScope
supervisorScope
. The coroutineScope
function fails if a child fails, and cancels all children in that case. Its purpose is mostly to do some parallel decomposition of work while suspending the current coroutine, I wouldn't say it's primarily about error handling. Even for supervisorScope
I would say it's mostly about the same thing, but with the specific change in behaviour for error handling.Nick Allen
11/16/2021, 5:41 PMwithContext(uncaughtExceptionHandler) {
supervisorScope {
...
}
}
Casey Brooks
11/16/2021, 5:41 PMcoroutineScope
cancels all of its own children, but failure/cancellation of itself or any of its children does not bubble up and cancel the parent coroutine automatically. Instead, it throws an exception which can be caught and handled manually, rather than just immediately cancelling the entire coroutine, parents, siblings, and all.dimsuz
11/16/2021, 5:41 PMCoroutineScope
, exception in any of launch
-ed coroutines will cancel all the scope, and any other currently running coroutines, plus error hander for this scope will receive only one exception. But if I'll use a supervised scope (in any way you've suggested above), then failed launch
wont bring everything down and my scope will be able to log/report-to-ui/whatever and then it can continue launching new coroutines in itself.