# coroutines


11/30/2020, 10:02 PM
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
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
with the cause being the actual exception. Is that expected? Or is there something weird going on there?
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
field is set to the actual underyling exception (e.g


12/01/2020, 1:00 AM
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


12/01/2020, 1:11 AM
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?
So I guess I'm missing how the exception won't be hit within the select?