in Either<Error, Foo>, Error is not that, it's usually a sealed class with the full range of things that can go wrong with that thing, no more, no less, eg
sealed class ChangePasswordErrors {
class NotAuthenticated() : ChangePasswordErrors()
class ChangePasswordError() : ChangePasswordErrors()
class ReusedPassword() : ChangePasswordErrors()
}
and no, languages should not add weird syntax to deal with Either, Option, Try etc. Just call map, flatMap, fold.
> in Either<Error, Foo>, Error is not that
This is confusing. On the JVM `Error` and `Exception` are both subclasses of `Throwable`. If you meant a specific error type, give it another name. (I used `MyError` in the comments above.)
> sealed class ChangePasswordErrors {
If some kind of failure has to be handled, In Kotlin you can write:
sealed class ChangePasswordResponse {
class Success(): ChangePasswordResponse()
class NotAuthenticated() : ChangePasswordResponse()
...
Enjoy your callback hell.
Not sure what you mean by callback hell, I've never experienced that using Either. I just pass the Either from the db layer or whatever to the resource layer or whatever, where I fold it into a 200 with the requested thing or a 4xx or 5xx or whatever depending on the MyError (which is usually a sealed class that lists everything that can go wrong with the thing)
But to use that `Either` object ergonomically languages do add extra syntax. Rust with the `?` and Scala with the for-comprehension.
The interactions with HOFs are also subtle.
In Rust it requires a smart use of type params for `collect`.
In Scala (following the Haskell tradition) there's the pair of coloured functions `traverse` and `map`. But `traverse` is only available in third-party functional programming libraries (Cats or Scalaz). So out of the box there isn't a way to cleanly `map` a function that returns the `Either` type.
> now we're catching ALL exceptions, yay
Your example is not that different from upcasting.