Hi chaps, could someone explain the deal with the ...

# arrow

[Krystian Rybarczyk]

Hi chaps, could someone explain the deal with the BIO ? I have seen a commit by @simon.vergauwen merged into arrow-fx and then I’ve seen it reverted. Is there a rational somewhere on GitHub maybe that I could go through? Or maybe someone would not mind explaining real quick what happened there? 🙂

[stojan]

IO<A> is now suspend fun blah(): A
(because of suspend, there is an implicit possibility to fail with Throwable )


that means that instead of IO<E, A> you can use: suspend fun blah(): Either<A, B>

[raulraja]

@Krystian Rybarczyk what Stojan said and also take a look at how the IO like operators work over suspend directly without nesting. https://arrow-kt.io/docs/fx/async/

[Krystian Rybarczyk]

thanks guys, that makes sense! I’ve also found this PR https://github.com/arrow-kt/arrow-fx/pull/169 which sheds some light.
What I still find confusing though is that e.g. in the aforementioned PR you can see suggestions to use

Either.fx { 
  someComputationThatThrowsExc()
}

having tried that I noticed that fx is depracted in favour of simply either {}. In other places though (e.g. docs: https://arrow-kt.io/docs/integrations/kotlinxcoroutines/ )
I found Either.catch{} being used. What confuses me is that

Either.catch {
   someComputationThatThrowsExc()
}

is safe to use (catches the exception and wraps it into Left(Exception), whereas either{} simply propagates the exception. Any reason for the difference in behaviour? Should I prefer one over the other?

[raulraja]

It's just either instead of Either.fx

[raulraja]

All computation blocks for data-types have the type name in lowercase and some of them will include binding for more than just monads

[Krystian Rybarczyk]

makes sense, any reason though why it doesn’t catch exceptions thrown inside them? like Either.catch?

[raulraja]

Other builders like monoidal ones for Foldable are posible now with arrow.continuations and are currently in development

[raulraja]

Not all builders can capture exceptions. You can still bind either.catch{ boom }() inside an either block

[Krystian Rybarczyk]

oh right, that’s a good point, haven’t thought of that! Thanks! 🙂

[raulraja]

Prefer suspend over io and prefer suspend versions of the builders inside

[raulraja]

The suspended versions let's you mix either, suspend, etc.

[Krystian Rybarczyk]

nice summary, thanks @raulraja! 🙂

[Krystian Rybarczyk]

Sorry, just to clarify @raulraja: if I go for Either + suspend I don't even need the 'arrow-fx' dependency, do I?

[raulraja]

you do for all the async and concurrent stuff like parMapN, parTraverse, Schedule, Streams etc.

[raulraja]

arrow-fx-coroutines has all you need for streams and IO like ops over suspend

[raulraja]

IO will be removed soon once we go through the deprecation cycle.

[Krystian Rybarczyk]

right! thanks! 🙂

[Krystian Rybarczyk]

one more actually, sorry. How do I use resources safely in this approach? For IO there is bracket() . What about suspend Either?

[stojan]

https://github.com/arrow-kt/arrow-fx/tree/master/arrow-fx-coroutines#resource-safety

[Krystian Rybarczyk]

🤦 there is another dependency `arrow-fx-coroutines`… any chance to add that to the docs?

[stojan]

PRs are welcomed I guess 😁

[stojan]

Or please create an issue 🙂

[stojan]

I was also surprised it was a separate package from arrow-fx

[raulraja]

it had no dependencies on arrow-fx but should be distributed with arrow-fx too if it’s not currently

[raulraja]

when we remove IO that is the core of arrow-fx

[Krystian Rybarczyk]

thanks guys for all the help, I think I’m finally sorted 😁