What is the best practice of rethrowing CancellationException if I am catching all exceptions? Do I ...

# coroutines

[neworldlt]

What is the best practice of rethrowing CancellationException if I am catching all exceptions? Do I need to rethrow CancellationException at all?

val foo = runCatching { bar() }.getOrNull()  // or similar try-catch block

[gildor]

yes, you have to rethrow it, otherwise you hide cancellation

[gildor]

though, coroutine itself is cancelled, it will be checked only on next suspend point

[neworldlt]

always? It means runCatching() with failback is illegal inside coroutines

[gildor]

it’s not illigal, it’s just hides cancellation

[gildor]

you can implement own version of runCatching, if you use it a lot, which rethrows CancellationException

[neworldlt]

Ok. I suppose the worst case of hiding cancellation is to let other coroutines continue to work unexpectedly. Am I right?

[gildor]

yes, it delays cancellation, in some cases it can be a problem, anyway, it’s not good itself

[gildor]

this why catchign all exceptions is usually not a good idea

[gildor]

and was one of the main “cons” of adding Result to stdlib

[neworldlt]

I agree. But in many UI cases, you are needed failbacks for any error, so programmers just catch-all exception.

[neworldlt]

I am thinking to create a safe pair of runCatching and try versions only for coroutines with a lint check which do not permit the original version to be used in coroutines

[neworldlt]

Thanks for explanation! 🙇

[streetsofboston]

That's why I added this bug/feature-request a while ago:
https://github.com/Kotlin/kotlinx.coroutines/issues/1814

[allan.conda]

Just recently had the same concern, unfortunately the proposal above has not had an update in a while.
@streetsofboston did you end up just using your solution in your project and wrote your own lint for it?
Or perhaps you found a better approach for error handling (like not using the stdlib api at all)

[streetsofboston]

Yes, but without a (new) lint .