newbie question: I have a method which returns Uni...

# arrow

[noiano]

newbie question: I have a method which returns Unit because it just writes out a file … such method can obviously fail is something goes wrong… I’ve used Try<Unit> to capture this … it doesn’t feel quite right 😅

[pakoito]

As Derek said, what you're doing is described as an effect. It's a side-effect in the sense that you're changing the world, in this case writing a file, but you'd like for that side effect to be pure, composable, error handling and all things nice. Wrapping a side-effect makes it what we call an effect.

Try has most of those properties but fails one, it isn't deferred and gets executed immediately. Others like IO and Observable do have the same properties of Try, and laziness on top. Fun thing is, suspend functions also behave the same way.

So at some point instead of composing Try inside suspend functions or IO or Observable, you just use those everywhere in a way that's compatible and consistent.

And this reason is why we're going to phase out Try over time. We want the effect APIs to be used to prevent IO<Try<A>> or suspend fun bla(): Try<A> just for error handling

[noiano]

thank you very much for your answers ….

[noiano]

I actually did want to have a synchronous evaluation because I was invoking a spark action … I needed to be synchronous .. I’m now reading whether IO supports synchronous invocation

[raulraja]

IO is heavily optimized for synchronous invocations

[raulraja]

all effects are synchronous unless you move to new pools

[noiano]

ook … I’ll check out the docs … basically try.invoke is similar to IO.invoke for what concerns synchronous invocation, right?

[pakoito]

yes

[noiano]

thank you 🙂