4 ms·
> it doesn't require weird special syntax But to use that `Either` object ergonomically languages do add extra syntax. Rust with the `?` and Scala with the for
by ackfoobar 2y ago
> it doesn't require weird special syntax
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.
val foo: Either<Exception, Foo> = // Either is covariant
myClass.getFoo() // returns Either<MyError, Foo>
- vips7L 2y agoOdersky actually hates Either and refuses to use it in Scala for errors.
- mrkeen 2y agoI find this extremely weird. Why even use Scala then? Is it just for the implicits and long build times?
- bedobi 2y agothe 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)