I've got some code that is basically a hierarchy of sub-tasks that I think would be a good fit to migrate to coroutines, but I've got some dumb questions trying to get a few things straight. 1. Is the proper way to propagate a failure up the chain (from, say any child task in that hierarchy) to define a set of custom exceptions to encode different events and use those? If so, is an exception typically used even for a non-error "finished" case? (one of the sub-tasks can finish on its own for a non-error reason, so I could define something like a "FinishedSuccessfully" exception for that? Or is there a better pattern to use there?) 2. If object A has a coroutinescope defined and creates object B--which will launch its own child coroutines--and I want object B's coroutines to be launched within object A's coroutinescope, is the best way to just have object A pass its scope to object B in the ctor (or in function calls)? Or is there a better way to (implicitly?) have B 'inherit' A's coroutine scope?

1. Exceptions should never be used to represent a “success” value, especially since if a coroutine throws an exception in a CoroutineScope it will cancel sibling coroutines as well as itself. You should go either with Roman E.’s strategy of using sealed class hierarchies or result types to represent success/failure for everything except I/O issues or define a set of exceptions you want to throw on failures and be very strict about handling those exception types. 2. Yes, if Object B’s coroutine scope’s lifetime should be tied to that of Object A, then Object A should pass its coroutine scope to Object B to be used by it. If you want Object B to be able to be constructed on its own, you can set a coroutine context as a default parameter to Object B’s constructor to be used when none is passed.

Thanks, Evan! I'll check out that article.

If that’s the case you could report the status of your jobs via a channel. The first one to complete can send its computation result over the channel and whatever launched the jobs can cancel all the other coroutines as necessary

Yeah, I was wondering about that, too. I have a similar mechanism in place now, but I was thinking I'd be able to get rid of a fair bit of code if the exception model worked/was approprriate.

Child jobs of a coroutine can be retrieved via the current coroutine’s job - https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-job/children.html

What if I want to detect if any one child in the whole tree has completed?

That’s what the channel would be good for. You can pass the channel along as deep as you want and listen to it. When a child job reports it’s successful you can cancel all child jobs at the top of your concurrency tree and it will percolate downward

Ok, so this would be one channel created by the parent that got passed as a

SendChannel

to all children tasks, basically?

Yep!

Ok, thanks Evan...I'll play around with that.

Good luck!

👍