未来[A]与未来[Throwable \\ / A]

Question

Why do some people bother to represent failure in a scala.concurrent.Future using scala's Either or scalaz's \\/ instead of using the failed state of the Future?

How do you handle errors then and how do you chain calls on the happy path?

---

Update with some examples:

converting Akka's Future[A] to Future[Either[Exception,A]]

Scalaz Task - the missing documentation This one answers the why part, and suggests using scalaz.EitherT for chaining calls (that's for \\/ , what about Either or Try ?), but I wonder if one should ever use Future.failed , on what conditions, etc, and how to check failure.

I'm not sure if this is a widespread practice though, that's why I'm asking. :)

Answer 1

I personally use Either inside a future when I have "failures that I can expect" and can do something to recover from them. Especially if I need to make information about possible failures explicit to external users of API

sealed trait UserServiceError
case object UserDbNotAvailable extends UserServiceError
case object UserNotFoung extends UserServiceError

def getUser(id: Long): Future[UserServiceError \/ User]

This code is much more explicit about what failures can happen. In some cases it can be important.

The same can be achieved with Future[User] and Future.recover but in this case information about possible failures is not in type (can be in documentation)

However I agree that it's very controversial design decision, because Try is already designed for failure handling.

Answer 2

I treat the failed state of Future the same way I treat exceptions: they're for unexpected failures that indicate either programming errors or system failures like OutOfMemoryError s. As such they're not expected to be caught or handled except in a very high-level "retry the whole task" way.

Failed futures are not very typesafe (a failure is just Throwable ), and can conflate these system-level failures with a more semantic failure that can be handled in a predictable way. So if I have a failure "within" my system, eg Unauthorized , then I'd rather represent that as an Either , something like Future[Unauthorized \\/ MessageData] . Then there are three possible states:

• Success(\\/-(data)) - success
• Success(-\\/(unauthorized)) - "expected" failure. Something that I know how to handle specificly, eg by displaying a particular message to the user or returning a particular return code. Should not set off an alert for the programmer.
• Failure(throwable) - unexpected, system-level failure. Can only be handled with a generic error page or some such. Should be setting off monitoring and alerting the programmer.

I used to use a monad transformer to make composing the happy path easier (ie EitherT[Future, Unauthorized, MessageData] ), which works very well, though now I'm looking at a more generic approach (my scalaz-transfigure library).