5 ms·

I wrote the first version of the API I'm currently working on in that exact mindset in Scala with the Play framework. It basically boils down to everything retu

I wrote the first version of the API I'm currently working on in that exact mindset in Scala with the Play framework. It basically boils down to everything returning `Either[Error, X]` where X is whatever the service is returning. I came to dislike this approach because most of the time the error doesn't happen and it's just wasted code that's a bit verbose. So now I'm moving into Akka and going to allow well-defined exceptions to throw that get handled by a supervisor. It was nice to know errors were handled, but I came to the opposite opinion that exceptions truly are exceptional and errors are an instance of the exceptional taking place. Shrug, the bottom line is being disciplined in error-handling. I know there's varying views on this approach, but I really like crafting method signatures that indicate what they are intended to return rather than `Either` for everything. There's places where `Either` is great like registration where a bad password isn't really an "exception" but user error.

PeCaN 11y ago
I think (?) Scala has proper monads (but they're a little weird) which would let you avoid the verbose extra code. Generally it just involves implementing map and flatMap on your Either type, or something like that. Disclaimer: not a Scala developer.
acjohnson55 11y ago
If you don't really care about the details of the unhappy path, just use Option. The real problem with exceptions is that they crash the whole program, but it's really difficult to know you've accounted for all possible exceptions. With pattern matching on an Option, Either, or Validation, you'll get a compile-time warning if you haven't accounted for all branches. Checked exceptions, like in Java, also have this property, they're just really awkward to use.