When to use the rejection branch

[quanganhtran]

Hi! I am trying to draw a rough connection to Scala cats-effect and here is my understanding so far: It looks like Future a b is similar to IO[Either[B, A]] instead of just IO[A], due to the rejection branch. Because errors during IO execution is also hidden under the context in the same way Futures need to explicitly handle fatal errors with forkCatch.

That leads me to another question: when should I use Future rejection instead of my own Either (or Result etc.), especially since the latter is also usable in synchronous operations, while Future a b is exclusively asynchronous?

[Avaq]

It looks like Future a b is similar to IO[Either[B, A]] instead of just IO[A],

That's right. You can think of a Future as being IO + Either + Async/Cont.

when should I use Future rejection instead of my own Either (or Result etc.)

The simplest answer to this is: when you want to.

Fluture "mixes in" the Either type for two reasons:

1. Because in JavaScript, when we're dealing with Async IO, we're usually already dealing with potential failure. And so it'd be very common to have Futures with Eithers inside. It's just more convenient to have it already be part of the type to lower the amount of type juggling you have to do.
2. Because Fluture is originally meant to be an alternative to Promises, and since Promises have a rejection branch that is commonly used for flow control, so should Fluture.

Neither of these reasons are forcing you to use the rejection branch, though. If you'd rather stick with your own success/failure type, you can pretend the rejection branch doesn't exist, and use value to run your Futures. One thing to look out for in this case is that functions like node make use of Fluture's rejection branch, but a simple call to coalesce (Either.Left) (Either.Right) would put you back in the resolution branch.

[quanganhtran]

Thank you for the insight! I think I might actually try to use rejection branch as much as possible and provide some intermediate functions for interop with Either. Future a b doesn't need a monad transformer to be ergonomic unlike Future+Either x.map(_.map(fn))

[Avaq]

Future a b doesn't need a monad transformer to be ergonomic

Exactly! :D

The (minor, in my experience) drawback of the more ergonomic EitherT (IO) (read; Fluture) is that you don't really know why something gave you a Future. Is it because of branching? Because of async? Both? IO involved? If you'd keep separate types your code would be more explicit.. but also a pain to work with. ;)