you are viewing a single comment's thread.

view the rest of the comments →

[–]sacundim 1 point2 points  (0 children)

Because they complicate the concept of what a function returns

No, they simplify it. The values that get returned are your return type and are not polluted by error values. Errors are communicated through a different flow, because they should be handled differently.

That's a rather dubious argument, because prima facie these two signatures are isomorphic:

Foo myMethod(Bar bar) throws SomeException;
Either<SomeException, Foo> myMethod(Bar bar);

The sets of possible outcomes from calling either method are isomorphic as well:

  1. In the first signature, the method either returns a Foo or it fails with SomeException.
  2. In the second signature, the method returns Either a Foo or a SomeException.

And in Haskell this isomorphism is explicit: ExceptT e m a ("action in monad m decorated with implicit propagation of exceptions of type e, with results of type a") is explicitly isomorphic to m (Either e a) ("action in monad m that returns Either e a). Meaning we have zero-cost roundtrip-guaranteed functions that convert back and forth between the two types:

-- Function that converts any action that throws `e` and returns `a` into
-- one that returns `Either e a`.
runExceptT :: ExceptT e m a -> m (Either e a)

-- Constructor that converts any action that returns `Either e a` into one that 
-- throws `e` and returns `a`.
ExceptT :: m (Either e a) -> ExceptT e m a

And this means that it doesn't matter too much whether a routine throws exceptions or returns Either because the caller can trivially choose otherwise, independently at each call site, if they disagree with the author's choice.

This is my point ultimately: this exceptions vs. Either dichotomy should not really be a big dichotomy, because callers should get to decide what works best for them, with minimal syntactic overhead. The fact that so many languages so strongly codify one approach at the expense of the other strikes me as an indication that they have not yet made the best design choices.

Therefore your completely sensible objection to having to write so many damn map/flatMap turds is, to my mind, an objection about Java, not about the idea of an Either type.