the difference is that in catch (Error e), you're actually catching the Error type, the superclass of exception
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()
}
or whatever (but I could have made that clearer)
and no, languages should not add weird syntax to deal with Either, Option, Try etc. Just call map, flatMap, fold.
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()
...
Good poit re using MyError, that is indeed what I meant in the Either case
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)
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
or whatever (but I could have made that clearer)and no, languages should not add weird syntax to deal with Either, Option, Try etc. Just call map, flatMap, fold.