Hi, I've noticed that today exceptions support for...

# swift-export

[Waldemar Kornewald]

Hi, I've noticed that today exceptions support for suspend functions was merged (https://github.com/JetBrains/kotlin/commit/ef3d8cc606e3d3024b8fcd07be733630e993ddd2).
This commit also maps CancellationException and any subclasses to Swift's CancellationError. You probably already considered this, but I'd like to understand the reasoning: Since CancellationError is a struct instead of a protocol it's impossible to add the original Kotlin exception to CancellationError. For subclasses of Kotlin's CancellationException this results in a loss of information since all of them map to CancellationError. It also doesn't preserve the original exception if it bubbles out through Kotlin -> Swift -> Kotlin. Isn't the Swift world already used to working with multiple different cancellation error types (e.g. from PromiseKit) such that it would be acceptable to map to a different exception type which preserves the original Kotlin exception?

[Artem Olkov]

Hello there.

Do you rely on subclassing of CancellationException in production? If so - how do you solve this problem at the moment?

Do you mind providing an example of a code, demonstrating the problem you are talking about?

[Waldemar Kornewald]

Yes this distinction is sometimes important. The simplest case would be withTimeout which uses a special TimeoutCancellationException which one has to distinguish from a full coroutine cancellation. Sometimes we define custom subclasses of CancellationException because that's the only exception type which is (by convention) re-thrown and bubbles up through all layers in the code (without triggering error handling logic) in order to signal a cancellation to an outer layer, but doesn't cause a full coroutine cancellation. It's the same principle as withTimeout where an inner layer signals cancellation and an outer layer catches that exception and handles it in some special way - without letting it bubble up further. (side-note: withTimeout has a design flaw because TimeoutCancellationException should only happen within the block, but not bubble out of the withTimeout function call and instead get converted to an actual non-cancellation error type)

[Artem Olkov]

Our current strategy for exporting kotlin exceptions allows for very limited communication, and doesn’t preserve error types/hierarchies. Within this limitations, we decided it is more important to communicate error reason (cancellation) than anything else.

Please vote for a ticket to demonstrate that you need such support 🙂