Semantically speaking, which is more idiomatic? `E...

# arrow

[Chris Paul]

Semantically speaking, which is more idiomatic? Either<Error, Result> with an associated NotFound error type or Either<Error, Result?>

[raulraja]

Hi @Chris Paul, I’d prefer the first version if there are more concerns than NotFound since it let’s you deal with it alongside all other errors. Otherwise you start seeing multiple places where error handling takes place first for the left then for the absence of results in the right. Having said that both options guarantee all cases so i’d say it’s more a stylistic choice?

[Chris Paul]

the second version felt closer to standard kotlin to me, eg let?.{ } etc

[Chris Paul]

but it does mean that I have to do additional null checks

[tginiotis]

if the app logic is built to handle errors coming from Left, then having a Right nullable type also representing some sort of error state seems unidiomatic to the app and would require separate null handling. I vote for the first option

[Chris Paul]

if something doesn't exist, it's not necessarily an error state though

[Chris Paul]

it's just the absence of a value, returned without error

[raulraja]

Left doesn’t imply Errors either. Left implies exceptional cases whatever those are. It seems nullability here is one of those. But using .let does not make it for me more Kotlin idiomatic and extra pattern match case

[Chris Paul]

hmm

[Chris Paul]

perhaps i'm being too narrow in my view of what Left is

[Chris Paul]

if it's ok for something to not have a value, without that being due to a downstream error, my thinking was to treat it as a nullable right, since it's not a failure scenario

[Chris Paul]

but I am interested in what others think sinice it is still all quite new to me

[raulraja]

Left it’s literally short-circuiting control flow when computing over Either indicating an exceptional case. That is why is not considered by map and flatMap. But Either as a data structure it’s used for more than error handling. It’s used also for cases like controlling recursion and in general all kinds of short-circuiting without using exceptions. It can also be seen as a right biased union type which is a higher model than errors.

[raulraja]

In practice people use Either mostly when building system to control errors but you can use it for much more for example:

Option<A> == Either<Unit, A> == A?

[raulraja]

depending on the context you can see Either as a replacement for other types

[raulraja]

You can also have Either<Error?, Result

[raulraja]

Left(null) would mean then value not found

[Chris Paul]

i suppose one reason for the Result? was to prevent short circuiting

[Chris Paul]

but perhaps I could also map a particular error code to a null instead

[Chris Paul]

I prefer a specific error type for not found, rather than a nullable Left, that feels a little strange to me

[raulraja]

If you can’t continue computing when Result is null then it also matches the Left case, if you place it in the right each time you bind your either or use map or flatMap you are going to have to check for null

[Chris Paul]

yea it was more that I want to continue if something is null, it's a little hard to explain

[Chris Paul]

it sounds like generally you prefer the idea of a null for absence rather than a nullable right though

[Chris Paul]

so perhaps I should go with that

[raulraja]

if you have a small snippet or example maybe we can see it in context but otherwise IMO it’s easier to program when the Right sides are not nullable.

[Chris Paul]

I guess i always viewed left as bad and right as ok, but that might be the wrong way of looking at it. Perhaps your suggestion is better and that left is for exceptional circumstances

[Chris Paul]

and not existing is an exceptional circumstance