4 ms·
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
by bedobi 2y ago
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.
- ackfoobar 2y ago> the Error type, the superclass of exception > 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() ... > Just call map, flatMap, fold. Enjoy your callback hell.
- bedobi 2y agoGood 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)