`CoroutineScope.cancel` doesn't seem to work at le...

# coroutines

[Don Mitchell]

CoroutineScope.cancel doesn't seem to work at least in the kotlin playground or I'm missing something. I expected the following to cancel on i==6 but it doesn't. It throws the error after the loop finishes.

import kotlinx.coroutines.*

@OptIn(DelicateCoroutinesApi::class)
suspend fun main() = coroutineScope {
    repeat(10) { i ->
        keepRunningUnlessFatal {
            if (i == 3) {
                println("throwing ISE")
                throw IllegalStateException("Illegal 3")
            }
            if (i == 6) {
                println("throwing OOM")
                throw OutOfMemoryError("OOM")
            }
            println("i ${i}")
        }
    }
 
}

suspend fun <T> CoroutineScope.keepRunningUnlessFatal(
    message: String = "Continuing execution after exception",
    block: suspend () -> T
): T? = try {
    block()
} catch (e: VirtualMachineError) {
    this.cancel("FATAL_ERROR_MSG", e)
    null
    // HERE - uncomment to see difference
    //throw e
} catch (e: InterruptedException) {
    this.cancel("FATAL_ERROR_MSG", e)
    null
} catch (e: LinkageError) {
    this.cancel("FATAL_ERROR_MSG", e)
    null
} catch (e: CancellationException) {
    this.cancel(e)
    null
} catch (e: Exception) {
    println(e)
    println(message)
    null
}

[ephemient]

cancellation is cooperative. nothing in repeat or keepRunningUnlessFatal checks if the scope is alive

[ephemient]

it would be observed if you called any function that actually suspends (like suspendCoroutine or things built on similar primitives, as most suspending functions are), or if you explicitly called ensureActive()

[Don Mitchell]

yeah, i did ^^ in the toy example using both ensureActive() and delay(i.milliseconds) and it behaved as expected. good to know

[Don Mitchell]

Is that preferable to just throw e after the call to cancel?

[trevjones]

if the scope is cancelled is there even anything left to throw to?
we typically pepper this after all our runCatchings when in a suspend fun

.onFailure { currentCoroutineContext().ensureActive() }

[Don Mitchell]

The throw seems to stop the coroutines non-cooperatively. That is, without waiting for the next suspend point.

[trevjones]

Yeah peeling back ensureActive it just throws the CancellationException from the job so similar way to break out. I suspect the only real difference is down to the behavior of the CoroutineExceptionHandler in your Context since CancellationException is a documented special case?

[trevjones]

IIRC the reason we spread ensureActive in our try/catch pattern is just to ensure we are not accidentally consuming CancellationException like we would an IOException and keeping a coroutine alive longer than we should

[CLOVIS]

More info about what Trevor is describing: https://medium.com/better-programming/the-silent-killer-thats-crashing-your-coroutines-9171d1e8f79b