[joostdevries]

The monadic approach to exceptions like it's done here has the downside of having to encode all your business logic in maps and flatmaps. All the intermediary functions will have to return Try. And all the Try values have to combined into one. That type fidding code feels like cruft that doesn't add much value.

And I say that having developed in Scala for years and years.

Of course there's still sometimes when you want processing of other items to proceed, even though this one has failed. And that's where Try is really essential. So that's where we use it only: at the topmost level.

It's only at that top level that we wrap the call in a Try. And that works rather well.

One reason to do it like this is that we want to leverage the design philosophy of Kotlin. And not be writing Scala or Haskell in Kotlin ). And Kotlins philosophy when it comes to exceptions turns out to be: exceptions. Which is apparent in Kotlin coroutines, channels and flows.

) that's also why we try to stay away from Arrow

[ragnese]

Definitely fair points. I do feel like I'm swimming upstream even when I'm using the built in Result class in Kotlin.

Truth is, I rather be writing Rust, but I need the JVM sometimes. ;)

[vmchale]

> All the intermediary functions will have to return Try.

That's the advantage of the monadic/functorial approach: they don't!