将协程上下文显式传递给异步调用会产生不同的异常处理行为与将其安装在封闭的 scope 中

Question

The following code outputs both the "Handled by exception handler" and the "Caught exception" messages:

import kotlin.coroutines.*
import kotlinx.coroutines.*

fun main() {
    val eh = CoroutineExceptionHandler { _, e -> println("Handled by exception handler") }
    val context = eh + Job()

    CoroutineScope(context).launch {
        val res = async<String> { throw RuntimeException() }
//        val res = async<String>(context) { throw RuntimeException() }

        try {
            println("Result: ${res.await()}")
        }
        catch (e: Throwable){
            println("Caught exception")
        }
    }


    Thread.sleep(1000)
}

But if I swap which "val res" line is commented in, I only get the "Caught exception" message. Why does explictly providing the CoroutineContext (which includes the exception handler) to async result in the exception handler not handling the exception?

Answer 1

The answer is buried in the documentation, here :

Normally, uncaught exceptions can only result from coroutines created using the launch builder. A coroutine that was created using async always catches all its exceptions and represents them in the resulting Deferred object.

and here :

The parent job is inherited from a CoroutineScope as well, but it can also be overridden with corresponding coroutineContext element.

In the first case:

val res = async<String> { throw RuntimeException() }

Kotlin creates the context for the new coroutine by adding a new Job instance that is the child of the job inherited through the coroutine scope. Therefore when this coroutine fails, it notifies its parent, which then takes it to the installed exception handler.

In the second case:

val res = async<String>(context) { throw RuntimeException() }

context already contains a Job element. This overrides the behavior above and no new job is created for the new coroutine. Therefore its Job element does not point to the scope's job as the parent. When it fails, the coroutine does not pass the exception to the handler as per the quoted documentation, and it also does not pass it to the nonexistent parent.

Lesson learned: never pass a context with a Job element to a child async builder.