PlainBytes.BrittleChain 0.11.0

There is a newer version of this package available.
See the version list below for details.
dotnet add package PlainBytes.BrittleChain --version 0.11.0                
NuGet\Install-Package PlainBytes.BrittleChain -Version 0.11.0                
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="PlainBytes.BrittleChain" Version="0.11.0" />                
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add PlainBytes.BrittleChain --version 0.11.0                
#r "nuget: PlainBytes.BrittleChain, 0.11.0"                
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install PlainBytes.BrittleChain as a Cake Addin
#addin nuget:?package=PlainBytes.BrittleChain&version=0.11.0

// Install PlainBytes.BrittleChain as a Cake Tool
#tool nuget:?package=PlainBytes.BrittleChain&version=0.11.0                

<p align="center"> <img width="128" align="center" src="assets/icon.png" > </p>

<h1 align="center"> Brittle chain </h1>

<p align="center"> Small opiniated library to simplify chaining actions and their error handling with the result pattern. </p>

The problem

There are many cases such as application boundaries, IO operations, network calls, etc. where we the possibility of failure can be high. If failure happens, this must be communicated back to the caller, which could be done by throwing, returning null or other "invalid" values. Now if we do this, that must be checked somehow, most likely with a try-catch, null check, type check, all of this results in a lot of noise which has nothing to do with the actual problem that we are trying to resolve.

This pattern is nothing new, functional programing has solved it long time ago with Monads.

Maybe has value, maybe failed?

The Result type has a simple role, transport to Value or the Exception. In either way defines a simple, unified way to make decisions.

if (result.Succeeded)
{
    // do somthing
}
else
{
    // we have failed
    LogError(result.Exception);
}

Chained execution

We have improved our error checking, however this will still results in Check, Do, Check, Do pattern. This is what Brittle chain tries to simplify:

var result = data.ToResult()
                .Chain(ActionOne)
                .Chain(ActionTwo)
                .Chain(ActionThree);

This is a typical chain, if any of the actions return a result which failed, the rest of the actions will not be called.

That is a bit cleaner but what else can we do?

var result = data.ToResult()
                .TryDo(ActionOne) // Try to execute, catch exception if fails but pass along your source.
                .TryChain(ActionTwo) // Try to execute, catch exception if fails.
                .Select(FunctionThree) // Do if has value and retrun a different {T}.
                .OnFail(LogError);

There are many possible scenarios especially when we start looking at Async operations as well.

var result = await data.AsMaybeAsync()
                .TryDoAsync(ActionOne) // ➡ await Task.Run(ActionOne), wrapped in a try-catch block
                .TryChainAsync(AsyncMethod) // ➡ await AsyncMethod(value), wrapped in a try-catch block
                .SelectAsync(FunctionThree); // ➡ return await FunctionThree(value)

There are many more overloads, please have a look at the samples app for more...

‼ DO NOT mix async with synchronous calls ‼

Key words

  • Do: "JUST DO" ➡ does not change source, does not break chain.
  • Chain: "DO IF" ➡ Execute if has value, does change source if fails, breaks chain.
  • Select: "CONVERT IF" ➡ Execute if has value, always changes source, breaks chain.
  • Try: "MIGHT BLOW" ➡ wraps the call into a try catch.
  • Map: "ERROR" or "SUCCESS" ➡ maps the two outcomes to a callback
Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 was computed.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 was computed.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
.NET Core netcoreapp2.0 was computed.  netcoreapp2.1 was computed.  netcoreapp2.2 was computed.  netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.0 is compatible.  netstandard2.1 was computed. 
.NET Framework net461 was computed.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen40 was computed.  tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.
  • .NETStandard 2.0

    • No dependencies.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
0.15.0 183 8/27/2023
0.14.0 166 8/27/2023
0.13.0 161 8/27/2023
0.12.0 151 8/27/2023
0.11.0 160 8/27/2023
0.1.0 161 8/27/2023