Dealing with existing C# functions that mutate state

[rhemsuda]

I've created a helper class for document management prototype that I'll be presenting to my team shortly.

One thing I was curious about was how to manage existing .NET library usage. A lot of their functions do indeed mutate state, which is technically against the rules in FP.

I'm wondering if there are sufficient ways to manage Pure and Impure functions either with the LanguageExt library or others. I've seen the [Pure] attribute that I wanted to play around with and was curious what your thoughts were on this topic.

I have the following code:

using Azure.Storage.Blobs;

public static class BlobStorageHelper
{
    public static IO<Either<Error, Unit>> UploadToBlobStorage(string connectionString, string containerName, string blobName, byte[] data, bool overwrite = false)
        => lift(() =>
        {
            try
            {
                var blobServiceClient = new BlobServiceClient(connectionString);
                var blobContainerClient = blobServiceClient.GetBlobContainerClient(containerName);
                var blobClient = blobContainerClient.GetBlobClient(blobName);

                using (var stream = new MemoryStream(data))
                {
                    blobClient.Upload(stream, overwrite: overwrite);
                }

                return Right<Error, Unit>(unit);
            }
            catch (Exception ex)
            {
                return Left<Error, Unit>(Error.New(ex.Message));
            }
        });

    public static IO<Either<Error, byte[]>> DownloadFromBlobStorage(string connectionString, string containerName, string blobName)
        => lift(() => {
            try
            {
                return GetContainerBlobClient(connectionString, containerName, blobName).Match(
                    Some: blobClient => 
                    {
                        using (var ms = new MemoryStream())
                        {
                            blobClient.DownloadTo(ms);
                            return Right<Error, byte[]>(ms.ToArray());
                        }
                    },
                    None: () => Left(Error.New("Could not open blob container client."))
                );
            }
            catch (Exception ex)
            {
                return Left(Error.New(ex.Message));
            }
        });

    private static Option<BlobClient> GetContainerBlobClient(string connectionString, string containerName, string blobName)
        => new BlobServiceClient(connectionString)
        .GetBlobContainerClient(containerName)
        .GetBlobClient(blobName);
}

The piece I'm concerned with us this:

using (var ms = new MemoryStream())
{
    blobClient.DownloadTo(ms);
    return Right<Error, byte[]>(ms.ToArray());
}

Not because it doesn't work, but mostly from a matter of principal.

I will be writing a developer manifesto for this team and I want to ensure that I'm not contradicting myself when I say "No mutation", as this is technically mutating state of the memory stream.

Is there a way I can do this in a more "functional" approach? Or maybe just some patterns I can introduce for any time where we have to deal with things like "using" blocks or "try-catch", that are otherwise necessary when dealing with built-in functions that were not written with immutability in mind?

[louthy]

The short answer is "yes", anything that does mutation or touches an external changeable thing (IO), should be wrapped up in IO. And wrapping existing .NET APIs in more declarative interfaces, although a bit annoying, is really the best approach. Otherwise you end up fighting against the libraries throughout the code-base, rather than encapsulating that in one place.

The [Pure] attribute doesn't do anything really. But, IDEs like Rider will assume that a [Pure] method must return a value and so if you ignore the result anywhere then it will give you warnings, so it's only useful for that (and maybe communication to other devs).

So, as with your previous efforts you're nested two layers of things that already have error handling support. IO<A>, although its errors are exceptions, has lots of primitives for handling the errors (like .MapFail, @catch, .Catch, Choice, and the choice operator |). So, you don't need to try/catch at all, you can just use those primitives.

When IO works with exceptions, in its failure handling primitives, it converts the Exception to an Error. So it does all of what you're trying to do by nesting the two types. You can also lift your own bespoke non-exceptional errors into the IO monad by calling IO.fail(Error).

The one place where you will want to try/catch is when you call .Run. If you haven't caught the failures inside the IO computation then that's only place an exception will be realised.

If you still want something that does explicit catching of errors on Run, then you can use Eff<A>, as that's essentially the IO monad with Run method that returns Fin<A> (Error | A).

So, I would factor your code like this...

First, create an AppError type to manage your known errors:

public static class AppError
{
    public enum Code
    {
        BlobClientFailedToOpen = 10000,
        // ... add more here as you need
    }

    public static readonly Error BlobClientFailedToOpen =
        Error.New((int)Code.BlobClientFailedToOpen, "Could not open blob container client.");

        // ... add more here as you need
}

Then your code (without the excessively long names ;-) )

public static class BlobStorage
{
    public static IO<Unit> Upload(
        string connectionString,
        string containerName,
        string blobName,
        byte[] data,
        bool overwrite = false) =>
        from client in GetContainerBlobClient(connectionString, containerName, blobName)
        from stream in use(() => new MemoryStream(data))
        from _      in UploadFromStream(client, stream, overwrite)
        from __     in release(stream)
        select unit;

    public static IO<byte[]> Download(
        string connectionString,
        string containerName,
        string blobName) =>
        from client in GetContainerBlobClient(connectionString, containerName, blobName)
        from stream in use(() => new MemoryStream())
        from _      in DownloadToStream(client, stream)
        let data = stream.ToArray()
        from __     in release(stream)
        select data;
    
    static IO<Response> DownloadToStream(BlobClient client, Stream stream) =>
        lift(() => client.DownloadTo(stream));
    
    static IO<Response<BlobContentInfo>> UploadFromStream(BlobClient client, Stream stream, bool overwrite) =>
        lift(() => client.Upload(stream, overwrite: overwrite));
        
    static IO<BlobClient> GetContainerBlobClient(
        string connectionString,
        string containerName,
        string blobName) =>
        IO.lift(() => new BlobServiceClient(connectionString)
                        .GetBlobContainerClient(containerName)
                        .GetBlobClient(blobName))
            | AppError.BlobClientFailedToOpen;
}

But, what I would do is I would realise that accessing Azure blob-storage is a key piece of functionality. I'd want to make that into a more featured and declarative thing. I'd also notice that these appear everywhere:

    string connectionString,
    string containerName,
    string blobName

They clutter up the interface and the resulting code will have to manage them and propagate them through from application configuration or something like that.

So, firstly, I'd make sure those strings can't accidentally be provided in the wrong order, by making them into stronger types:

public readonly record struct ConnectionString(string Value);
public readonly record struct ContainerName(string Value);
public readonly record struct BlobName(string Value);

Then I'd create an environment type that carries the configuration and current-state:

/// <summary>
/// Blob context environment
/// </summary>
public record BlobEnv(
    ConnectionString ConnectionString, 
    Option<ContainerName> ContainerName, 
    Option<BlobName> BlobName,
    Option<BlobClient> BlobClient);

Next, I'd create a new Blob<A> type that wraps up ReaderT and IO. Reader can handle an environment value passed through it:

/// <summary>
/// Blob monad
/// </summary>
public record Blob<A>(ReaderT<BlobEnv, IO, A> runBlob) : K<Blob, A>
{
    public static Blob<A> Pure(A value) => new(ReaderT<BlobEnv, IO, A>.Pure(value));
    public static Blob<A> Fail(Error value) => new(ReaderT<BlobEnv, IO, A>.LiftIO(IO.fail<A>(value)));
    public static Blob<A> LiftIO(Func<A> f) => new(ReaderT<BlobEnv, IO, A>.LiftIO(IO.lift(f)));
    public static Blob<A> LiftIO(Func<Task<A>> f) => new(ReaderT<BlobEnv, IO, A>.LiftIO(IO.liftAsync(f)));
        
    public Blob<B> Map<B>(Func<A, B> f) => this.Kind().Map(f).As();
    public Blob<B> Select<B>(Func<A, B> f) => this.Kind().Map(f).As();
    public Blob<A> MapFail(Func<Error, Error> f) => this.Kind().Catch(f).As();
    public Blob<B> Bind<B>(Func<A, K<Blob, B>> f) => this.Kind().Bind(f).As();
    public Blob<B> Bind<B>(Func<A, K<IO, B>> f) => this.Kind().Bind(f).As();
    public Blob<C> SelectMany<B, C>(Func<A, K<Blob, B>> b, Func<A, B, C> p) => this.Kind().SelectMany(b, p).As();
    public Blob<C> SelectMany<B, C>(Func<A, K<IO, B>> b, Func<A, B, C> p) => this.Kind().SelectMany(b, p).As();
    public Blob<C> SelectMany<C>(Func<A, Guard<Error, Unit>> b, Func<A, Unit, C> p) => SelectMany(a => Blob.lift(b(a)), p);

    public static implicit operator Blob<A>(Lift<A> lift) => LiftIO(lift.Function);
    public static implicit operator Blob<A>(Pure<A> pure) => Pure(pure.Value);
    public static implicit operator Blob<A>(Error fail) => Fail(fail);
    public static implicit operator Blob<A>(Fail<Error> fail) => Fail(fail.Value);
    public static Blob<A> operator |(Blob<A> ma, K<Blob, A> mb) => ma.Choose(mb).As();
    public static Blob<A> operator |(Blob<A> ma, Error mb) => ma.Choose(Fail(mb)).As();
    public static Blob<A> operator |(Blob<A> ma, CatchM<Error, Blob, A> mb) => ma.Catch(mb).As();
    public static Blob<A> operator >> (Blob<A> ma, K<Blob, A> mb) => ma.Bind(_ => mb);
    public static Blob<A> operator >> (Blob<A> ma, K<Blob, A> mb) => ma.Bind(_ => mb);
    public static Blob<A> operator >> (Blob<A> ma, K<IO, A> mb) => ma.Bind(_ => mb);
    public static Blob<Unit> operator >> (Blob<A> ma, K<Blob, Unit> mb) => ma.Bind(_ => mb);
    public static Blob<Unit> operator >> (Blob<A> ma, K<IO, Unit> mb) => ma.Bind(_ => mb);
}

The methods are mostly optional, but it just makes everything easier.

Next, I'd add some extensions to Run the monad, conversion As, and some more convenience extensions:

/// <summary>
/// Blob extensions
/// </summary>
public static class BlobExtensions
{
    public static Blob<A> As<A>(this K<Blob, A> ma) =>
        (Blob<A>)ma;
    
    public static IO<A> Run<A>(
        this K<Blob, A> ma, 
        ConnectionString connectionString, 
        Option<ContainerName> containerName = default, 
        Option<BlobName> blobName = default) =>
        ma.Run(new BlobEnv(connectionString, containerName, blobName, None)).As();
    
    public static IO<A> Run<A>(this K<Blob, A> ma, BlobEnv env) =>
        ma.As().runBlob.Run(env).As();
    
    public static Blob<C> SelectMany<A, B, C>(this IO<A> ma, Func<A, K<Blob, B>> b, Func<A, B, C> p) => Blob.liftIO(ma).SelectMany(b, p).As();
    public static Blob<C> SelectMany<B, C>(this Guard<Error, Unit> ma, Func<Unit, K<Blob, B>> b, Func<Unit, B, C> p) => Blob.lift(ma).SelectMany(b, p);
}

Next, I would implement the traits:

• Monad<Blob>
• Alternative<Blob>
• Fallible<Error, Blob>
• Readable<Blob, BlobEnv>

These expose the capabilities of the underlying ReaderT and IO monads...

/// <summary>
/// Blob trait implementations
/// </summary>
public partial class Blob : 
    Monad<Blob>, 
    Alternative<Blob>,
    Fallible<Error, Blob>,
    Readable<Blob, BlobEnv>
{
    static K<Blob, B> Monad<Blob>.Bind<A, B>(K<Blob, A> ma, Func<A, K<Blob, B>> f) =>
        new Blob<B>(ma.As().runBlob.Bind(x => f(x).As().runBlob));

    static K<Blob, B> Functor<Blob>.Map<A, B>(Func<A, B> f, K<Blob, A> ma) =>
        new Blob<B>(ma.As().runBlob.Map(f));

    static K<Blob, A> Applicative<Blob>.Pure<A>(A value) =>
        new Blob<A>(ReaderT.pure<BlobEnv, IO, A>(value));

    static K<Blob, B> Applicative<Blob>.Apply<A, B>(K<Blob, Func<A, B>> mf, K<Blob, A> ma) =>
        new Blob<B>(mf.As().runBlob.Apply(ma.As().runBlob));

    static K<Blob, A> Choice<Blob>.Choose<A>(K<Blob, A> fa, K<Blob, A> fb) =>
        new Blob<A>(fa.As().runBlob.Choose(fb.As().runBlob).As());

    static K<Blob, A> MonoidK<Blob>.Empty<A>() =>
        new Blob<A>(ReaderT.lift<BlobEnv, IO, A>(IO.empty<A>()));

    static K<Blob, A> Fallible<Error, Blob>.Fail<A>(Error error) =>
        new Blob<A>(ReaderT.lift<BlobEnv, IO, A>(IO.fail<A>(error)));

    static K<Blob, A> Fallible<Error, Blob>.Catch<A>(
        K<Blob, A> fa, Func<Error, bool> Predicate,
        Func<Error, K<Blob, A>> Fail) =>
        new Blob<A>(
            new ReaderT<BlobEnv, IO, A>(env =>
                fa.Run(env).Catch(Predicate, e => Fail(e).Run(env))));

    static K<Blob, A> Readable<Blob, BlobEnv>.Asks<A>(Func<BlobEnv, A> f) =>
        new Blob<A>(ReaderT.asks<IO, A, BlobEnv>(f));

    static K<Blob, A> Readable<Blob, BlobEnv>.Local<A>(Func<BlobEnv, BlobEnv> f, K<Blob, A> ma) =>
        new Blob<A>(ReaderT.local(f, ma.As().runBlob));

    static K<Blob, A> MonadIO<Blob>.LiftIO<A>(IO<A> ma) =>
        new Blob<A>(ReaderT.liftIO<BlobEnv, IO, A>(ma));
}

Now onto the core functionality of Blob:

public partial class Blob
{
    public static Blob<A> pure<A>(A value) => 
        Blob<A>.Pure(value);
    
    public static Blob<A> fail<A>(Error value) => 
        Blob<A>.Fail(value);
        
    public static Blob<A> liftIO<A>(IO<A> ma) =>
        MonadIO.liftIO<Blob, A>(ma).As();

    public static Blob<A> liftIO<A>(Func<A> ma) =>
        MonadIO.liftIO<Blob, A>(IO.lift(ma)).As();

    public static Blob<A> liftIO<A>(Func<Task<A>> ma) =>
        MonadIO.liftIO<Blob, A>(IO.liftAsync(ma)).As();

    public static Blob<A> lift<A>(Option<A> ma) =>
        ma.Match(Some: pure, None: fail<A>(Errors.None));

    public static Blob<Unit> lift(Guard<Error, Unit> guard) =>
        liftIO(guard.ToIO());
    
    public static Blob<A> bracket<A>(K<Blob, A> ma) =>
        bracketIO(ma).As();

    public static Blob<BlobEnv> env =>
        Readable.ask<Blob, BlobEnv>().As();
    
    public static Blob<A> local<A>(Func<BlobEnv, BlobEnv> f, Blob<A> ma) =>
        Readable.local(f, ma).As();

    public static Blob<ConnectionString> connectionString =>
        env.Map(e => e.ConnectionString);

    public static Blob<ContainerName> container =>
        env.Bind(e => lift(e.ContainerName))
            | AppError.BlobContainerNotSet;
    
    public static Blob<BlobName> name =>
        env.Bind(e => lift(e.BlobName))
            | AppError.BlobNotSet;

    public static Blob<BlobClient> client =>
        env.Bind(e => lift(e.BlobClient))
            | AppError.BlobClientNotSet;
    
    static Blob<BlobClient> openClient =>
       (from conn in connectionString
        from cont in container
        from name in name
        select new BlobServiceClient(conn.Value)
                       .GetBlobContainerClient(cont.Value)
                       .GetBlobClient(name.Value))
        | AppError.BlobClientFailedToOpen;
    
    public static Blob<A> withClient<A>(Blob<A> ma) =>
        from c in openClient
        from r in local(e => e with { BlobClient = c}, ma)
        select r;     
        
    public static Blob<A> with<A>(BlobName name, Blob<A> ma) =>
        local(e => e with { BlobName = name }, ma);     
    
    public static Blob<A> with<A>(ContainerName container, BlobName blob, Blob<A> ma) =>
        local(e => e with { ContainerName = container, BlobName = blob }, ma);     
}

So, we supporting construction, lifting, accessing the BlobEnv, withClient which creates a local-context with an opened client, with for creating local blob context. It also deals with the errors.

Now, we can rewrite your original functions (but with a consistent interface between Stream and byte[]):

public partial class Blob
{
    public static Blob<Unit> upload(byte[] data, bool overwrite = false) =>
        bracket(from stream in use(() => new MemoryStream(data))
                from _      in upload(stream, overwrite)
                select unit);

    public static Blob<Unit> upload(Stream stream, bool overwrite = false) =>
        withClient(client.Map(c => c.Upload(stream, overwrite: overwrite)).Map(_ => unit));

    public static Blob<byte[]> download() =>
        bracket(from stream in use(() => new MemoryStream())
                from _      in download(stream)
                select stream.ToArray());

    public static Blob<Unit> download(Stream stream) =>
        withClient(client.Map(c => c.DownloadTo(stream)).Map(_ => unit));
}  

So, now we don't have to deal with and manage the configuration, it all gets dealt with automatically. Every new function you write doesn't need to deal with it, and every composition of Blog monads also don't need to.

For example, before:

var operation = from data  in BlobStorageHelper.Download(connectionString, containerName, blobName)
                from data2 in ModifyData(data)
                from _     in BlobStorageHelper.Upload(connectionString, containerName, blobName, data2, true)
                select unit;

After:

var operation = from data  in Blob.download()
                from data2 in modifyData(data)
                from _     in Blob.upload(data2, true)
                select unit;

If you wanted to change blobs on-the-fly:

var blob1 = new BlobName("blob-1");
var blob2 = new BlobName("blob-2");

var operation = from data  in Blob.with(blob1, Blob.download())
                from data2 in modifyData(data)
                from _     in Blob.with(blob2, Blob.upload(data2))
                select unit;

When you Run the operation, you can either provide just the connection-string, or connection-string+container+blob-name, to pre-seed the computation with the environment you want. And the result of running it is just an IO<A>, which you can then use alongside any other IO.

This for me is the power of creating bespoke monadic types for various domains in the application. The Blob type is, for sure, some typing. But, it's once only, can be re-used in every project you do, and is properly declarative. And, probably less typing overall once you take into account all of the manual management of configuration and state that is needed without the Blob type.

Anyway, that's just how I would approach it, sorry if it's thrown a spanner in the works!

[louthy]

This is the updated AppError btw:

public static class AppError
{
    public enum Code
    {
        BlobClientFailedToOpen = 10000,
        BlobClientNotSet,
        BlobContainerNotSet,
        BlobNotSet
    }

    public static readonly Error BlobClientFailedToOpen =
        Error.New((int)Code.BlobClientFailedToOpen, "Could not open blob container client.");

    public static readonly Error BlobClientNotSet =
        Error.New((int)Code.BlobClientNotSet, "Trying to use blob-client features without opening it first: use Blob.withClient");

    public static readonly Error BlobContainerNotSet =
        Error.New((int)Code.BlobContainerNotSet, "Blob container hasn't been set, use Blob.with");

    public static readonly Error BlobNotSet =
        Error.New((int)Code.BlobNotSet, "Blob hasn't been set, use Blob.with");
}

[louthy]

By the way, I realise I didn't answer the question about Stream. Yes, Stream is problematic, it's one of those .NET 1.0 APIs that is particularly ugly. I'm surprised to see it used in the Azure API because I thought MS had moved more towards channels and the like.

You need to consider what the Stream is for (I mean the reading one, where it just fills up a MemoryStream), that has no value over the one that yields a byte array. If yielding the byte array chunks as they stream down is valuable then it's worth doing your own implementation of Stream, package it inside something else (immutable), and then use that to yield the chunks.

Pipes can do that, but might be overkill, and the new Source type (that yields a StreamT upon subscription) can do that, but is still WIP.

[rhemsuda]

Thanks for the detailed response! I've got another question that is related to this. Is there any way to get rid of try-catch blocks entirely? I need a way to deal with exceptions and turn them into expectations with Error type.

I'm also wondering if there is a way to remove use of 'await' or if it is necessary when dealing with external libraries that use Task?

For example:

public Eff<Either<AddDocumentError, Document>> AddDocumentAsync(
        DocumentDbContext context,
        Document document
    ) => 
        GetDocumentByIdAsync(context, document.ID).Bind(res => res.Match(
            Some: existingDoc => lift(() => Left<AddDocumentError, Document>(new DocumentExistsError(existingDoc))),
            None: () => DocumentEntity.FromDocument(document).Match(
                Right: entity => liftIO(async () => 
                {
                    await context.AddAsync(entity);
                    await context.SaveChangesAsync();
                    return Right<AddDocumentError, Document>(document);
                }),
                Left: err => lift(() => Left<AddDocumentError, Document>(new DocumentBlobStorageError(document.ID, err.Message)))
            )
        ));

This code still technically has some imperative code within the curly-braces. I'm trying to have a rule-of-thumb for my team where we don't use curly-braces anywhere in our program, and instead using lambdas for everything. await and try-catch seem to be some of the last pieces of the puzzle for me in going from imperative code to functional code in C#.

[louthy]

I've got another question that is related to this. Is there any way to get rid of try-catch blocks entirely?

Not sure I fully understand the question, it seems a little broad. But both Eff and IO have combinators that will allow you to catch exceptions and turn the exceptions into Error values. IO will throw (when you invoke Run) if exceptions aren't caught using either |, @catch, or .Catch. Whereas Eff won't throw at all and will always return a Fin<A>. So, Eff is what you want to stop all exceptions.

That obviously doesn't mean that exceptions are never expressed by any of the wrapped behaviours, it just meas that those types have primitives that deal with exceptional events.

I'm also wondering if there is a way to remove use of 'await' or if it is necessary when dealing with external libraries that use Task?

Task doesn't have to be awaited, you can wrap it up in an IO monad and then just work with the IO monad type with LINQ. You only need to await a Task if you want to do sequential operations (statements).

So with this:

liftIO(async () => 
{
    await context.AddAsync(entity);
    await context.SaveChangesAsync();
    return Right<AddDocumentError, Document>(document);
}

You can extract the individual methods (I'm guessing at the types):

IO<Unit> Add(Context context, Entity entity) =>
    liftIO(e => context.AddAsync(entity, e.Token));

IO<Unit> SaveChanges(Context context) =>
    liftIO(e => context.SaveChangesAsync(e.Token));

Then the original expression is await free:

from _ in Add(context, entity) >>
          SaveChanges(context, entity)
select Right<AddDocumentError, Document>(document)

Obviously, at some point you will need to invoke the underlying IO computation to realise the value (usually in Main or in a web-request/response handler). You are most likely to benefit from awaiting the resulting Task. However, it still isn't entirely necessary. Take a look at this ASP.NET Core test-app:

app.MapGet("/sync",
           () =>
           {
               var effect = yieldFor(1000).Map("Hello, World");
               return effect.Run();
           });

app.MapGet("/async",
           async () =>
           {
               var effect = yieldFor(1000).Map("Hello, World");
               return await effect.RunAsync();
           });

The first handler, sync, runs an IO operation (yieldFor) which yields for 1000 milliseconds before returning. It uses the synchronous Run method.

The second handler is the same, but it uses the asynchronous RunAsync method (which is awaited).

In NBomber benchmarks both perform exactly the same. There's no thread starvation and the performance is equal. So, really, you don't have to use await at all (which was one of the goals of the v5 refactor). Some people are more comfortable using it though and there are times when you want the Task and to not await it, or you may want to await multiple results, so RunAsync works better then.

So, really it's about getting the ugly .NET APIs you're using and wrapping them up into fine-grained IO monads. Then lifting those into either an Eff monad (which you seem to be using), or take some of my earlier advice and build bespoke monads around the various frameworks (as I showed with the Blob monad).

I'd love to provide my own wrappers at some point for some of the major libraries like ASP.NET Core, EntityFramework, AWS/Azure, etc. but there are only so many hours in a day. I decided to try writing an Avalonia project over the weekend to try it out and I wanted to rip the whole thing to pieces and start building a proper declarative UI library for it! But again, I have too much on my plate to do all of that right now.

So, I think if you pay a small investment upfront in packaging up the handful of core libraries that you use, it will pay dividends down the track.

[rhemsuda]

“Whereas Eff won't throw at all and will always return a Fin<A>. So, Effis what you want to stop all exceptions.” Can you elaborate on this? Are you saying that I don’t need to catch exceptions inside of an Eff monad? Where would they go? Is there any implicit functionality occurring here or do I need to explicitly define how Exceptions get translated to Errors in all cases? I want it to be as unlikely as possible that an exception occurs at runtime due to forgetting to wrap something in a try catch. I’m introducing this to a lot of developers who have never done functional programming before and who frankly aren’t the greatest at exception handling to begin with (lol), hence why I’ve been putting this new stack together. Appreciate your help 🤘🏼

…

On Mon, Nov 18, 2024 at 4:47 PM Paul Louth ***@***.***> wrote: I've got another question that is related to this. Is there any way to get rid of try-catch blocks entirely? Not sure I fully understand the question, it seems a little broad. But both Eff and IO have combinators that will allow you to catch exceptions and turn the exceptions into Error values. IO will throw (when you invoke Run) if exceptions aren't caught using either |, @catch, or .Catch. Whereas Eff won't throw at all and will always return a Fin<A>. So, Eff is what you want to stop all exceptions. That obviously doesn't mean that exceptions are never expressed by any of the wrapped behaviours, it just meas that those types have primitives that deal with exceptional events. I'm also wondering if there is a way to remove use of 'await' or if it is necessary when dealing with external libraries that use Task? Task doesn't have to be awaited, you can wrap it up in an IO monad and then just work with the IO monad type with LINQ. You only need to await a Task if you want to do sequential operations (statements). So with this: liftIO(async () => { await context.AddAsync(entity); await context.SaveChangesAsync(); return Right<AddDocumentError, Document>(document);} You can extract the individual methods (I'm guessing at the types): IO<Unit> Add(Context context, Entity entity) => liftIO(e => context.AddAsync(entity, e.Token)); IO<Unit> SaveChanges(Context context) => liftIO(e => context.SaveChangesAsync(e.Token)); Then the original expression is await free: from _ in Add(context, entity) >> SaveChanges(context, entity)select Right<AddDocumentError, Document>(document) Obviously, at some point you will need to invoke the underlying IO computation to realise the value (usually in Main or in a web-request/response handler). You are most likely to benefit from awaiting the resulting Task. However, it still isn't entirely necessary. Take a look at this ASP.NET Core test-app <https://github.com/louthy/language-ext/blob/main/Samples/TestBed.Web/Program.cs> : app.MapGet("/sync", () => { var effect = yieldFor(1000).Map("Hello, World"); return effect.Run(); }); app.MapGet("/async", async () => { var effect = yieldFor(1000).Map("Hello, World"); return await effect.RunAsync(); }); The first handler, sync, runs an IO operation (yieldFor) which yields for 1000 milliseconds before returning. It uses the *synchronous* Run method. The second handler is the same, but it uses the *asynchronous* RunAsync method (which is awaited). In NBomber benchmarks <https://github.com/louthy/language-ext/blob/main/Samples/TestBed.Web.Runner/Program.cs> both perform exactly the same. There's no thread starvation and the performance is equal. So, really, you don't have to use await at all (which was one of the goals of the v5 refactor). Some people are more comfortable using it though and there are times when you want the Task and to not await it, or you may want to await multiple results, so RunAsync works better then. So, really it's about getting the ugly .NET APIs you're using and wrapping them up into fine-grained IO monads. Then lifting those into either an Eff monad (which you seem to be using), or take some of my earlier advice and build bespoke monads around the various frameworks (as I showed with the Blob monad). I'd love to provide my own wrappers at some point for some of the major libraries like ASP.NET Core, EntityFramework, AWS/Azure, etc. but there are only so many hours in a day. I decided to try writing an Avalonia project over the weekend to try it out and I wanted to rip the whole thing to pieces and start building a proper declarative UI library for it! But again, I have too much on my plate to do all of that right now. So, I think if you pay a small investment upfront in packaging up the handful of core libraries that you use, it will pay dividends down the track. — Reply to this email directly, view it on GitHub <#1400 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSYKUMRLJNB5QHJ7O7BY32BJN57AVCNFSM6AAAAABQYN7EFCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZG4ZDANI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[louthy]

Can you elaborate on this? Are you saying that I don’t need to catch
exceptions inside of an Eff monad?

That's correct, it catches them without you having to intervene, but so does the IO monad in certain circumstances:

IO

• Catches and finalises in Bracket
• Catches and disposes any used resources in Fork
• Run and RunAsync don't catch, but do clean up resources on if an exception is thrown.
• Catches failures in Retry so it can retry
• Catches failures in Catch so that the Fail handler can be called.
• Propagates failures in Combine and operator |

Eff

• Gets all of the above because the Eff monad lifts the IO monad
• Run has a try/catch block to catch all other exceptions coming from the Eff computation.
  • This saves having to check for failure on every Bind operation, instead failures are caught in the failure combinators like @catch etc. and Run.

Is there any implicit functionality occurring here or do I need to explicitly define how Exceptions get translated to Errors in all cases?

The Error type has two sub-types: Exceptional and Expected. Exceptional can carry a regular System.Exception type. This allows any exception to be carried through the computation as an Error (whilst also keeping its stack-trace).

What you should do is use |, @catch, .Catch, .MapFail, and BiMap as close to the effects that you expect to throw non-exceptional exceptions and map them to Error types of Expected. That will give you more control over the how you deal with errors.

If you look at the Error type, you'll see lots of static constructor functions that deals with this for you:

public static Error New(Exception? thisException) =>
    thisException switch
    {
        null                               => Errors.None,
        WrappedErrorExceptionalException w => w.ToError(),
        WrappedErrorExpectedException w    => w.ToError(),
        ErrorException e                   => e.ToError(),
        TaskCanceledException              => Errors.Cancelled,
        OperationCanceledException         => Errors.Cancelled,
        TimeoutException                   => Errors.TimedOut,
        AggregateException a               => ManyErrors.FromAggregate(a),
        var e                              => new Exceptional(e)
    };
    
public static Error New(string message, Exception? thisException) =>
    new Exceptional(message, thisException ?? new BottomException());

public static Error New(string message) =>
    new Expected(message, 0, None);

public static Error New(int code, string message) =>
    new Expected(message, code, None);

public static Error New(int code, string message, Error inner) =>
    new Expected(message, code, inner);

public static Error New(string message, Error inner) =>
    new Expected(message, 0, inner);

public static Error Many(params Error[] errors) =>
    errors.Length == 0
        ? Errors.None
        : errors.Length == 1
            ? errors[0]
            : new ManyErrors(errors.AsIterable().ToSeq());

public static Error Many(Seq<Error> errors) =>
    errors.IsEmpty
        ? Errors.None
        : errors.Tail.IsEmpty
            ? (Error)errors.Head
            : new ManyErrors(errors);

As you can see there are some overloads of New that create Exceptional errors and some that create Expected errors. Anything that takes an Exception will become an Exceptional error. The only time that isn't always true is when the Exception is of type: WrappedErrorExpectedException or ErrorException. These two types (derived from Exception) are designed to carry an Error.

That all might sound a bit confusing, but there are two type hierarchies, one for Error and one for ErrorException. ErrorException is designed for when you have an Error and you can't return it, but you know something else can catch it.

If you call ToException() on an Error, you will get an ErrorException. If you then call Error.New with that ErrorException you will get that original Error back, without any loss of information.

The IO monad uses this so that it can all Error.Throw() to throw an ErrrorException hoping that something can catch it and understand that it's well defined error. Something that does catch that is Eff. So, for example, if the IO monad calls Errors.TimedOut.Throw(). Then Eff will catch that and give you an Error with the correct error-code and message (which can then be pattern matched using @catch(Errors.TimedOut, ...)

So, internally exceptions are being thrown. And if you use a debugger you may well see those flying about. But this is an optimisation to stop me having to check for failure on every bind and instead just have key functions (like @catch and Run) that do the catching and conversion back into well defined Error types for public consumption.

The AppError example from earlier in this thread is a good guide. If you make all of bespoke your error types derive from either Expected or Exceptional then you also don't need to use Eff<Either<YourError, A>>, you can just use Eff<A>, which would make your code more elegant. Also consider that you don't need bespoke error types at all and can just use the Error.New constructor functions. The only time you need bespoke error types is if you need to carry additional data with the error.