CancellationException inheriting from IllegalStateException can be error prone about kotlinx.coroutines HOT 5 OPEN

I am not really commenting on the proposal here (I'm definitely not against it), but I strongly disagree with the main example provided, and thus the listed upside 2.

You should most likely never catch IllegalStateException (I have yet to see a case where this is beneficial, and this example is not one of them). If you need to catch ISE because you know of the specific situation where it is thrown (like the checkNotNull for your token), I would 100% vote for using a dedicated exception type there and catch this one specifically. It is both more readable and more correct, because the intent is to catch this specific instance of ISE, not any ISE, so we can use the type system to express this.

That said, I'm also quite surprised that CancellationException is a subtype of IllegalStateException (I did not know that, and I have quite a bit of experience with coroutines).

from kotlinx.coroutines.

As far as I see, CancellationException is defined as:

public actual typealias CancellationException = java.util.concurrent.CancellationException

So perhaps the plan was to deal with Java's java.util.concurrent.CancellationException as if it was CancellationException thrown from coroutines ?

from kotlinx.coroutines.

Note that this is a change not just in the library, but in the language as well. The exception is defined in the standard library https://github.com/JetBrains/kotlin/blob/0938b46726b9c6938df309098316ce741815bb55/libraries/stdlib/src/kotlin/coroutines/cancellation/CancellationExceptionH.kt#L13, and the compiler notifies the Apple targets that it is fine for suspend functions to throw this CancellationException.

from kotlinx.coroutines.

Maybe this issue warrants a structured-concurrency label as well?

from kotlinx.coroutines.

@LouisCAD structured-concurrency is for a specific (backwards-compatible) project that aims to solve all (most) of the labeled issues with a dedicated API layer. This one, unfortunately, is much more profound

from kotlinx.coroutines.