I’m not sure I understand your argument here @mdedetrich. Nobody in the thread previously has mentioned using String as the error type for Either and the rest of your post implies that the best strategy you found was to use Either with a sealed trait of error values, which is exactly how Either is used by the rest of the community now.
As far as I can tell the problem with Try are far more significant than the problems with Either for functional error handling and it would break tons of existing code to change Try to be suitable.
Sorry if I missed it, but what is that abstraction? Personally I would expect the “most restrictive” way to represent a possible error to have at least these restrictions:
it can’t contain any other errors than those I expect
it can’t contain any other results than those I expect
it can’t contain something that’s neither an error nor a result, nor something which is both
Either satisfies all three of these requirements, as does scalactic.Or (which is isomorphic but with the roles of the type parameters swapped).
Is there a further restriction you’d like to have that would make Either no longer restrictive enough for you?
[citation needed]? Try was originally added in 2012 (2.9, I believe) in commit 7d206f3, with the acknowledgement that it was inspired by Twitter’s work. That’s hardly “original” in either sense of the word.
Yes, it should have have a specific error type representing Left which Either doesn’t have. Otherwise you cant distinguish between something that is an error vs something that is just representing a union.
I didn’t mean original in the sense that it was introduced by Scala, but original in the sense that it was the first type that was introduced which was meant to deal specifically with errors.
Sorry for taking so long to respond, completely forgot about the topic.
I’m looking over this old thread because the site decided to show it to me at the top, but it’s funny because Rust’s Result is just an Either. It has no restriction on the type of Err, it does not accumulate, it has a “right” bias. There’s only two significant differences:
Result, Ok and Err clearly convey intent; and
? as a shortcut for match { case ok @ Right(_) => ok case err @ Left(_) => return err } turns all definitions with return type Result into seamless Right-biased Either for comprehensions.
Years of use and multiple major releases of Scalaz and the for-all-purposes fork as Cats with the third major release almost out have not produced anything other than small syntactical helpers to Either (.asRight[A] and .asLeft[B] are really nice), Validated, and MonadError (which is essentially a Try without a fixed error type). Aside, I suppose, from ZIO, but what makes that one different is that it conflates multiple responsibilities.
And that’s pretty much all of this discussion: the problems with Either are the names used and lack of syntactic support for less cumbersome expressions; a result type with error accumulation would be useful; Try would be much more useful if it wasn’t tied to Exception.
As a side note, it would be really nice if there was short syntactic construct for early return of error/extraction of success on Try and Either-returning definitions. Something like a .getOrReturn() macro on both that expanded into a match with early return.
And, digressing, Rust’s exception handling is migraine-inducing. You think Either in Scala is bad? How about dozens of exception-handling libraries because there’s none in the standard library, and the most popular ones have been abandoned for a while?