Should I be using `kotlinx.coroutines.Cancellation...

# coroutines

[martmists]

Should I be using kotlinx.coroutines.CancellationException or kotlin.coroutines.cancellation.CancellationException? on JVM they're both linked to the same thing, but I don't know about other platforms and/or what the most "future-proof" version is.

[Joffrey]

On JS, WASM, and Native targets, kotlinx.coroutines.CancellationException is an alias of kotlin.coroutines.cancellation.CancellationException. You can see it in their KDocs:
https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-cancellation-exception/

[martmists]

Hmm, then isn't it worth considering deprecating, since it's always equal to kotlin.coroutines.cancellation.CancellationException? I feel like having it duplicated might lead to confusion

[Joffrey]

I'm not sure why it's this way, as I'm not part of the Kotlin team myself. I see that the coroutines library created some subclasses and maybe wanted the whole hierarchy to be in the same package. Usually the kotlin.coroutines package from the stdlib (not kotlinX) contains the primitives for the core language support of coroutines, so I'm not sure why they needed to represent cancellation there. I guess if you're using the kotlinx.coroutines library it makes sense to use the kotlinx CancellationException. I would also be happy to understand more if someone knows 🙂

[Joffrey]

Maybe @Dmitry Khalanskiy [JB] knows more? 🙏 (sorry to summon you specifically)

[Dmitry Khalanskiy [JB]]

CancellationException is useful often enough that adding a separate kotlin.coroutines.cancellation import just for it would cumulatively add a lot of useless noise.

[Joffrey]

And I suppose the stdlib does need a cancellation exception too? I thought cancellation was only introduced at the coroutines library level, but I might have missed it in the language primitives

[Dmitry Khalanskiy [JB]]

No, I don't think stdlib uses it anywhere. The Kotlin compiler knows about CancellationException because it has to highlight the definitions exported to Objective-C as throwing a CancellationException. Otherwise, Objective-C thinks of such exceptions as unexpected failures and crashes.