How to return Either<Error, T> in an idiomatic way

[EivindAntonsen]

Hi,
I am wondering how the idiomatic approach to returning Either<Error, T> would look like. Currently I am using a method I made myself public static Either<Exception, T> TryEither<T>(Func<T> function) which simply wraps a different function call which i then follow up with .MapLeft(exception => exception.ToError). This feels a little backwards and hacky, but the end result however is allright (Eithers everywhere).

My thinking is that anything that might fail where the error is something that should be handled by the application, the return value should be Either<Error, T> - which is why I use this function a lot.

I've seen Eff and Aff mentioned previously but I don't understand them. Can anybody chime in on how to use them, and if that is appropriate? The application is a standard webservice/api, nothing fancy.

[louthy]

Yep, Error was designed to represent both exceptional an non-exceptional errors. Exception converts to Error, so you could just catch the exception an convert it to Either<Error, A>.

Btw, Fin<A> is effectively Either<Error, A>, you just don't have to keep providing the left type-parameter.

There's some notes on the recent Error refactor which might help you decide which approach to take. Error will become even more embedded in this library as I extend it more.

[EivindAntonsen]

Thanks a lot. This was helpful. :)

On a related note, what is the correct way to handle a situation where computations might fail and you'll need to deal with resource cleanup? A chained from x in y where you're looking for a final Either<Error, T> but will need to do cleanup if something fails. I've just been using either .Bind() or the LINQ-way from x in y so far, but neither seems to cleanly handle that.

[StefanBertels]

I'm interested in (even) better solutions for this problem, too.

Currently I know of use expression: https://louthy.github.io/language-ext/LanguageExt.Core/Prelude/Resource%20using/

[louthy]

@StefanBertels You can see what I'm working on for v5, which has resource tracking an automatic clean-up.

It does make things like Either lazy, so I probably can't add it without some cunning alternative solution (or an understanding that using use would make a type lazy). But it's more likely to just exist for the function based (lazy) monads, like Try, TryOption, Reader, Eff, Aff, etc.

[louthy]

The prototype code is all in the DSL folder btw