You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When throwing any subclass of CancellationException from Kotlin, SKIE converts that to CancellationError and the information about the original Kotlin exception gets lost because CancellationError is just a struct and can't be subclassed. However, any other Kotlin exception gets preserved correctly.
Now we have the problem that our code uses subclasses of CancellationException to signal different kinds of cancellation. This is incompatible with how SKIE converts everything, including our custom subclasses into a general CancellationError that becomes useless as a signal.
Could you please either not convert every CancellationException into CancellationError or at least make it possible to turn the conversion feature on/off?
Another lossyness example: Kotlin code calls an interface which gets implemented by Swift and itself calls a Kotlin function. If the inner Kotlin function throws a specific CancellationException subtype and that becomes CancellationError in Swift and gets re-thrown, then the outer Kotlin code won't know what the original exception was.
The text was updated successfully, but these errors were encountered:
wkornewald
changed the title
CancellationError is lossy
CancellationError causes information loss
Feb 25, 2025
When throwing any subclass of CancellationException from Kotlin, SKIE converts that to CancellationError and the information about the original Kotlin exception gets lost because CancellationError is just a struct and can't be subclassed. However, any other Kotlin exception gets preserved correctly.
Now we have the problem that our code uses subclasses of CancellationException to signal different kinds of cancellation. This is incompatible with how SKIE converts everything, including our custom subclasses into a general CancellationError that becomes useless as a signal.
Could you please either not convert every CancellationException into CancellationError or at least make it possible to turn the conversion feature on/off?
Another lossyness example: Kotlin code calls an interface which gets implemented by Swift and itself calls a Kotlin function. If the inner Kotlin function throws a specific CancellationException subtype and that becomes CancellationError in Swift and gets re-thrown, then the outer Kotlin code won't know what the original exception was.
The text was updated successfully, but these errors were encountered: