I’m seeing something rather weird with the `result...

# arrow

[phldavies]

I’m seeing something rather weird with the result {} computation (arrow 1.1.3, kotlin 1.7.20, but also occurs in 1.6.21 at least). Notably, if you switch dispatcher within the computation as follows:

result {
    withContext(<http://Dispatchers.IO|Dispatchers.IO>) {}
    1
}

you end up with nested Success(Success(1)) , despite the return type being correctly Result<Int>.

Weirdly, using the following in it’s stead

private suspend inline fun <A> result(crossinline f: suspend ResultEffectScope.() -> A): Result<A> =
    effect { f(ResultEffectScope(this)) }.toResult()

Works as expected, but looks to be identical in implementation.

I’ve also realised I still have no idea when best to use runCatching {} vs result {} vs Either.catch {} 😳

[simon.vergauwen]

Result captures NonFatal including CancellationException, so it's a bit dangerous in that sense. It was build specifically for the Continuation runtime, and was originally marked as @InternalApi but people started using it anyways, and eventually convinced the Kotlin team to make it public. With a lot of explicit counter argumentation from Roman.

Either.catch is meant to wrap side-effects/FFI, and then transform it to E and continue with your user-domain rather than relying on Throwable everywhere.

[phldavies]

So for the normal use-case of wrapping throwing calls in either/effect it's better to use Either.catch. Is there much benefit of result {} over runCatching {}?

[simon.vergauwen]

Is there much benefit of result {} over runCatching {}?

There is no benefit of working with Result over Either. It's there to provide the same APIs over a type that already exists in Kotlin Std. The motivation/rationale of Arrow Core is to complement the Std, so that is what this does. I personally never use it, and always prefer working over E.

[simon.vergauwen]

You can avoid wrappers all together if you want with Context Receivers, and/or by creating extension functions `EffectScope<E>`/`Raise<E>` and just work over E directly. The APIs are also evolving more towards that.