Hello everyone, how would you best model the `Eith...

# arrow

[Andrei Bechet]

Hello everyone, how would you best model the Either<SomeFailure, Unit> case? Say I have to set something and don’t care about the result?
We found out the hard way that having Unit in there could be a potential problem since the compiler does not oblige us to see inside.
thanks

[Youssef Shoaib [MOD]]

Most of the time when your right value is Unit this means that you're doing a side effect, and so your best option here is to just use suspend normally since it allows you to handle errors and everything like that.

[Andrei Bechet]

agreed … unfortunately we’re just at the stage of no exceptions …not yet no side effects 🙂

[Youssef Shoaib [MOD]]

Hmmm, well as a temporary solution you can use some form of object that denotes a successful result. Something like object OperationSucceeded that can be used like Either<SomeFailure, OperationSucceeded> should work quite well for you. You'll just need to make sure that after you perform the setting of whatever value that you return the OperationSucceeded object.

[Andrei Bechet]

thanks, was thinking it the same lines but was not really sure

[Youssef Shoaib [MOD]]

Yeah it's basically the same design as the Unit idea but it ensures that the compiler won't insert the value for it automatically

[Marius Kotsbak]

Or return nullable failure object which is null in case of success?

[Andrei Bechet]

We still want the inflexions in the failure case, hence why we went the Either way

[Marius Kotsbak]

What is inflexions?

[Andrei Bechet]

LIke failure1 failure2 … etc
an operation can fail due to multiple reasons

[Marius Kotsbak]

You can make an ADT for failure cases (and possibly success also to avoid null).

[Marius Kotsbak]

Or standard lib Result?

[Marius Kotsbak]

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/

[Andrei Bechet]

last time I checked you cannot return that one outside your function

[Andrei Bechet]

plus we are really benefiting from the Either and we want to go towards a more functional implementation

[Marius Kotsbak]

Yeah, it is maybe not so functional. We actually are using a lot of Either<Throwable, Unit> for side effects (in suspend functions)

[Andrei Bechet]

We defined a Failure sealed class which has all the options we need. The moment we’re missing something we add it.
Speaking for myself … I don’t get much from most Throwables … simply too much cluttered info I don’t need. But that is another discussion 🙂 …
For the suspend case we need to do some steps before we can have it in place.

[Marius Kotsbak]

Yeah, I prefer other types as well, except maybe low level code modules that mainly/only gets errors from external APIs.