Does anyone has insights in the “Rich errors” feature that was announced? It looked similar to what ...

# arrow

[jean]

Does anyone has insights in the “Rich errors” feature that was announced? It looked similar to what Either does, didn’t it?

[David]

I believe they said experimental in 2.4 so probably in a year or so

[jean]

Yes, it’s a long time before we can use anything

[Emil Kantis]

I’m hoping it will let us use union error types even with Arrow, as I prefer the Arrow DSL. Do you think it might end up working?

[jean]

It looked like the pattern was fun somWork(): SuccessReturnType | FailureReturnType { ... } I wonder if the | operator is a shortcut to some sort of new Result type. Then arrow could create some extension types for whatever | will give to the developers

[Emil Kantis]

This is all speculation based on my impressions from the conference, but I think there's no inherent order to the types, just that they are meant to be different categories.. so if I have something like:

error class TransactionError
error class UserError

then a function might in theory return fun withdrawMoney(): TransactionId | UserError | TransactionError

If we instead stick with Either, then we could have Either<UserError | TransactionError, TransactionId> which would let us handle only the relevant error types without needing to have a common supertype for those two errors. This would be really neat for error handling IMO, since we get to keep the left/right semantics, with "raise returns", folds etc.

[jean]

That’s true

[simon.vergauwen]

The design is not finalised so it’s hard to say right now but it will either be a full blown replacement and we either soft deprecate it with a clear migration path (if that’s what the Arrow community wants), or we offer a nice integration between them where you can move back -and forth.

[Michael Friend]

i imagine with the limitation of error types needing to be final so you cant make sealed hierarchies of errors there's still some use for an Either type that doesnt have that limitation, although the union typealias approach for expressing multiple possible error will probably cover enough of the use cases for a sealed error type that it isnt worth having two different constructs for very similar ideas

[Youssef Shoaib [MOD]]

Either is still definitely useful, just like how Option is useful in face of null existing, because it allows arbitrary nesting of itself inside itself, which is useful in some scenarios. I suspect what we may do is make Either.Left an error data class, and then provide functions that return A | Either.Left, while still preserving functions that don't.

[simon.vergauwen]

This all feels like speculation until the design is final to be honest. Most importantly we'll have to think about binary compatibility, and not breaking dependent projects. Secondly, we'll have to think what is best for the (Arrow) community and we'll have to do some surveys, and polls. If any transition or deprecations take place it'll probably be a 2-3 year process before we'd eventually move to 3.x, and even though we might still provide a "fallback" module for those users that cannot migrate or do not want to migrate.