I ve setup Coroutine Scopes inside our Presenter class where

Question

I ve setup Coroutine Scopes inside our Presenter class where every child coroutine has one of 2 parent coroutines I m seeing some really odd behavior around `CoroutineExceptionHandler`s where after we receive a single exception every child coroutine immediately fails with the same exception again Code snippets on thread

spierce7 · Answer

From our base presenter ``` protected open val coroutineExceptionHandler CoroutineExceptionHandler = null private var mountScope = ComponentCoroutineScope private var viewScope = ComponentCoroutineScope protected val mountScope CoroutineScope get = mountScope protected val viewScope CoroutineScope get = viewScope private inner class ComponentCoroutineScope CoroutineScope private val baseJob = Job val isActive Boolean = baseJob isActive override val coroutineContext CoroutineContext get val job = Job parent = baseJob + Dispatchers Main return coroutineExceptionHandler let job + it job fun cancel baseJob cancel ``` In a child presenter class ``` override val coroutineExceptionHandler CoroutineExceptionHandler get = ApiCoroutineExceptionHandler apiExceptionHandler ```

gildor · Answer

Yes this is expected behavior

spierce7 · Answer

What do I do to work around it then I find this undesirable

gildor · Answer

Use SupervisorJob instead also see docs

spierce7 · Answer

which docs specifically I ve read them all a few times now at different times

gildor · Answer

About SupervisorJob

gildor · Answer

There are additional details about this behavior

gildor · Answer

spierce7 · Answer

ok thx Looks like you saved me again < gildor>

spierce7 · Answer

I literally just read this page again about exception handling I didn t even see this supervision section

gildor · Answer

+1

spierce7 · Answer

< gildor> So I just confirmed that fixed it This seems like dangerous undesirable behavior to me There are several things like this around coroutines i e when a coroutine is cancelled all it s child coroutines halt at their next suspension point I find these dangerous and undesirable

spierce7 · Answer

I kind of feel like I ve exchanged one set of concurrency problems and received a whole host of new ones that I m not familiar with RxJava was at least consistent but I feel like coroutines aren t

uhe · Answer

I tend to agree

streetsofboston · Answer

< spierce7> I don t agree E g you have a Coroutine that is busy downloading a bunch of data in parallel and the Coroutine reports the result of the downloads back to the caller e g combining meshing the downloaded results then when one download fails or cancels all should fail cancel This is where the `Job` comes in handy if it is tied to the Coroutine Scope s context If you don t want all other siblings to fail use `SupervisorJob` Not sure if I like the name though slightly smiling face

uhe · Answer

I think it depends on where you use coroutines most frequently in your daily work If you work a lot inside architectures that use presenters or similar constructs than this can seem like a counter intuitive default behavior

uhe · Answer

But it s probably also caused by the rather drastic change introduced by structured concurrency

spierce7 · Answer

< streetsofboston> I disagree i e For something as that takes as long as network traffic what I really want is for the other requests to continue processing in the background so that I can cache their results All I want is for their results to not not trigger a callback in the coroutine I ve cancelled

spierce7 · Answer

By cancelling all child coroutines at their next suspension point all you ve really done is create the possibility of ending up with inconsistent state somewhere downstream in a stateful object where one of your child coroutines went

gildor · Answer

This is not exactly default behavior you always choose between Job and SupervisionJob

spierce7 · Answer

If I call GlobalScope launch I m defaulted into this behavior

streetsofboston · Answer

But if the siblings are not canceled where do they report their results It depends Use Job or SupervisorJob on your use case That Job is a default that is arguable I agree

spierce7 · Answer

To opt out I have to do something special

gildor · Answer

Yeah you right Job is more default because it creating if scope doesn t have Job by default like GlobalScope which doesn t have any Job

spierce7 · Answer

To be clear Supervisor job doesn t stop child coroutines from being cancelled on their next suspension point That s another issue entirely that you can only solve by creating new coroutine scopes everywhere you want their to be a barrier

spierce7 · Answer

Are there any other uses for Supervisor job other than ensuring there isn t a bidirectional relationship between exceptions

gildor · Answer

Not sure what you mean by doesn t stop child coroutines from being cancelled SupervisorJob is not cancelled if one of child coroutines is cancelled Maybe you could show an example

gildor · Answer

Just for context there is a related issue about cancellation semantics also mentioned a few other related discussions <https github com Kotlin kotlinx coroutines issues 763>

Dico · Answer

The thing you may need < spierce7> is CoroutineStart ATOMIC

Dico · Answer

For operations that should not be cancelled halfway

Dico · Answer

In my opinion it is confusing what changes you need to make to opt out of the default behaviour which is pretty much to destroy everything when an exception occurs somewhere If it s cumbersome you can consider creating your own coroutine builders that crossinline your coroutine body into a try catch and handle the exceptions your way

spierce7 · Answer

< Dico> how sure are you that atomic does what I m advocating for

Dico · Answer

Read the docs and judge for yourself

Dico · Answer

Maybe mix it with `NonCancellable`