How to avoid accidentally catching `CancellationException`? For example, any inline (not suspending)...

# coroutines

[Mark]

How to avoid accidentally catching CancellationException? For example, any inline (not suspending) higher order function could innocently be catching Exception and converting to some sealed class. It knows nothing about coroutines and so would have no reason to give special treatment to CancellationException.

fun main() {
    runBlocking {
        val job = launch {
            test {
			    delay(1000L)
                println("finished long delay")
            }
            println("finished test")
        }
        delay(100L)
        job.cancel()
    }
}

inline fun test(block: () -> Unit) {
    try {
        block()
    } catch (e: Exception) {
        println(e.toString())
    }
}

// kotlinx.coroutines.JobCancellationException: StandaloneCoroutine was cancelled; job="coroutine#2":StandaloneCoroutine{Cancelling}@de0a01f
// finished test

[muliyul]

Change the name so it will hint it should be used inside coroutines

inline fun safeCoTry(block: () -> Unit) { 
    try {
        block()
    } catch (e: Exception) {
        if(e is CancellationException) // propogate
         throw e
        println(e.toString())
    }
}

[Mark]

Yes, I know how to rethrow it. It’s just that there are many inline functions (already defined) that know nothing about coroutines.

[muliyul]

from std lib or your own?

[Mark]

Internal shared code. So yes, I could just introduce coroutine dependency everywhere, but this doesn’t seem good to me. Regardless, also potentially an issue with 3rd party non-coroutine libraries.

[muliyul]

I don't think you have many options tbh.

[Mark]

Perhaps there should be a lint check for when an inline function catches Exception thrown from lambda argument.

[ephemient]

catching unknown exceptions without rethrowing them seems problematic in general, not just in this case

[Mark]

CancelletionException seems like a very different type of exception that perhaps deserves its own category, much like how Error is treated differently.

[ephemient]

for what it's worth, Java's InterruptedException is similar: used for Thread.interrupt(), should not be ignored, and extends Exception, not Error

[Mark]

It’s more the existence of inline higher order functions that makes this more of an issue.

[Adam Powell]

IllegalStateException in general (which CancellationException extends) tends to indicate something that shouldn't wrap/log and continue.