I'm observing something that I'm trying to nail do...

# coroutines

[bbaldino]

I'm observing something that I'm trying to nail down, but wondering if maybe it isn't a guarantee: I launch a couple tasks via val task = myScope.async { ... }, and then I wait on those deferreds in a select block. When a task throws, most of the time the exception I catch (around my select) is the actual exception thrown by the task. But sometimes it's a JobCancellationException with the cause being the actual exception. Is that expected? Or is there something weird going on there?

[bbaldino]

To be specific, sometimes the error logged is error: kotlinx.coroutines.JobCancellationException: Parent job is Cancelling; job=JobImpl{Cancelled}@436a4e4b. But when I debug and set a breakpoint, I see the cause field is set to the actual underyling exception (e.g MyException)

[kingsley]

Looks like working as expected to me

If the exception path was not hit within the select, it'll simply execute the empty block and finish while the loops continue to run. Any code that then tries to execute after the exception will throw cancellation since this exception will automatically cause the scope to be cancelled

On the other hand, if select executes on the async block that threw the exception, then that exception will simply propagate

Keep in mind that this is all executing within a single thread, so there is no real parallelism here

[bbaldino]

Maybe I'm misunderstanding how select works...I thought any completion of either task there would fire the handler, and the exception counts as a completion so I should always get that exception as the result?

[bbaldino]

So I guess I'm missing how the exception won't be hit within the select?