Are there any coroutines-friendly error handling f...

# coroutines

[Marko Mitic]

Are there any coroutines-friendly error handling functions? For example, some runCatching that doesn't catch CancellationException?
Would be nice to have some standardized solution (and IDE warnings on catching the CancellationException in coroutines)

[Marko Mitic]

I've tried making my version of runCatching but it can't return kotlin.Result because it's inline class 😞

[louiscad]

It's because kotlin.Result might change in the future, so the ABI of the inline class is not exposed to allow changes without breaking people with binary compatibility for JVM users that use libraries compiled before the changes.

[Marko Mitic]

I assumed so

[louiscad]

Why do you want to use kotlin.Result specifically?

[Marko Mitic]

I wanted to write version of runCatching that won't catch CancellationException. Ideally, it would be a simple update to codebase, ideally returning same type

[Marko Mitic]

I guess I can make my own Result with same api as kotlin.Result

[gildor]

You can add compiler flag to allow use Result as return type

[Marko Mitic]

That's probably very unsafe for libraries 😄

[gildor]

Yeah, for libraries it's not good, it would require consumer to use this flag too

[louiscad]

And would more importantly break after they decide to change the ABI of kotlin.Result, even with the flag activated (unless they add a mechanism to prevent compilation of such things, which is still breaking things and delaying update until library updates)

[Marko Mitic]

Am I on the right track here, does this makes sense?

public inline fun <R> coRunCatching(block: () -> R): Result<R> {
    return try {
        Result.success(block())
    } catch (e: CancellationException){
        throw e
    } catch (e: Throwable) {
        Result.failure(e)
    }
}

[louiscad]

LGTM. You're using your own Result, right?

[Marko Mitic]

Haven't coded it yet, but yes.

[louiscad]

You mean you haven't copy pasted it yet? 😉 (that said, might be a little easier to roll your own simplified version actually)

[gildor]

What is your use case for own result?

[gildor]

I mean if it's library maybe domain specific sealed class would be better solution than generic version that just returns some value or exception

[Marko Mitic]

Use case is that I'd use it instead of kotlin.Result, so that updating current code to coRunCatching is just changing name of fun called.

[louiscad]

You can also name it cancellableRunCatching, which IMHO is more accurate and makes it more obvious why it's used in place of stdlib's runCatching without having to look at the source of the function (which is impractical if not viewed from an IDE with checked out revision, like on VCS UIs or in-IDE diffs).