Since `Try` is deprecated, is the preferred replac...

# arrow

[kyleg]

Since Try is deprecated, is the preferred replacement for (non-suspending) Try { … } :
1. an explicit try { Either.right(…) } catch(e) { Either.left(…) } or
2. runBlocking { Either.catch { … } } (which is a suspend fun)

[pakoito]

1 for non-suspend functions, and Either.catch { } for suspend ones

[pakoito]

runBlocking a suspend function inline isn't great

[pakoito]

and we decided not to include 1 in the library because we don't want to encourage exception handling in non-suspend functions as a way of doing control flow

[pakoito]

understanding that there's a whole ecosystem out there that does it, so adding #1 to your codebase is okay if you understand the implications :D

[kyleg]

Yes, I agree on runBlocking inline. I’m updating docs that use Try with replacements in anticipation for Try being removed, and I’ve run into this issue a couple times.

For example, in the docs there’s DataTypeExamples.kt with a whole block of Try examples. The Either examples are fewer, so I’m trying to replace those Try with more Either .

The docs explicitly contrast the “old school” try/catch with newer Try {…}, so it seemed like try { Either.right } catch { Either.left } was a little inelegant considering it’d be contrasted with “old school” try/catch block 😛

[simon.vergauwen]

try/catch/finally works fine in pure code is because it can not fail on you there. In code with async jumps and cancelation it can work incorrectly.

[simon.vergauwen]

For that reason there is no real need for Try since try/catch with Either works just as well with less abstractions.

[kyleg]

Understood. I had thought of Try as just syntactic sugar for try/catch and hadn’t questioned whether functional purity played a role.

I suppose this is one reason IO and suspend fun are connected in Arrow. The issue around async jumps and error handling.

[Attila Domokos]

IO ftw!