Davish.Result.Extension 2.1.0

Davish.Result

A lightweight Result pattern for .NET. Model success and failure as values instead of throwing exceptions for expected error flows, and compose your operations into a single, short-circuiting pipeline with Then (sync and async).

• Explicit outcomes — Result and Result<TValue> make "this can fail" part of the type.
• Structured errors — Error carries a code, description, category, and per-field messages.
• Extensible categories — a set of built-in ErrorType values, extend it with your own.
• Fluent composition — chain steps with Then / ThenAsync; a failure skips the rest.
• Minimal API integration — convert a Result straight into an IResult with a configurable error-to-status-code mapping.
• Broad reach — Davish.Result/Davish.Result.Extension target netstandard2.0 and net10.0.

Installation

dotnet add package Davish.Result
dotnet add package Davish.Result.Extension          # Then / ThenAsync composition
dotnet add package Davish.Result.AspNetCore.Http    # Result -> Minimal API IResult (net10.0)

Everything lives in a single namespace:

using Davish.Result;

Quick start

Result<OrderConfirmation> confirmation = await ValidateRequest(request)
    .ThenAsync(CheckStockAsync)
    .ThenAsync(ChargeAsync)
    .ThenAsync(CreateOrderAsync)
    .Then(Confirm);

string message = confirmation.IsSuccess
    ? $"Order {confirmation.Value.OrderId} placed"
    : confirmation.Error.Description;

Each step runs only if the previous one succeeded. The first failure short-circuits the rest of the chain and flows through untouched.

Usage

Creating results

Result ok = Result.Success();
Result bad = Result.Failure(new Error("User.Locked", "The account is locked"));

Result<int> value = Result.Success(42);
Result<int> failed = Result.Failure<int>(new Error("Parse.Failed", "Not a number"));

Reading a result

if (result.IsSuccess)
    Use(result.Value);           // Result<T>.Value throws ResultValueUnavailableException if the result is a failure
else
    Log(result.Error.Description);

Implicit conversions

A value or an Error converts to a result implicitly, so factory methods can just return:

Result<string> GetName(int id)
{
    if (id <= 0)
        return new Error("Id.Invalid", "Id must be positive");   // Error  -> failed result

    return "David";                                              // value  -> successful result
}

Composing with Then

Then maps or binds the successful value; ThenAsync does the same for asynchronous steps. Mix them freely — the chain stays flat.

Result<string> result = Result.Success(2)
    .Then(x => x + 3)                      // map:  int -> int
    .Then(x => Result.Success(x * 10))     // bind: int -> Result<int>
    .Then(x => x.ToString());              // map:  int -> string

Result<Profile> profile = await FetchUserAsync(id)   // Task<Result<User>>
    .ThenAsync(LoadProfileAsync)                      // async bind
    .Then(p => p.WithDefaults());                     // sync map on the awaited result

Errors

Error describes what went wrong and is categorized by an ErrorType:

var error = new Error("User.NotFound", "User was not found", ErrorType.NotFound);

Built-in categories:

Field-level (validation) errors

Error.Fields holds messages keyed by field name. Build it fluently with AddFieldError:

var error = new Error("Validation", "One or more fields are invalid")
    .AddFieldError("Email", "Email is required")
    .AddFieldError("Password", ["Too short", "Must contain a digit"]);

// error.Fields["Password"] => ["Too short", "Must contain a digit"]

Custom error types

Declare application-specific categories as static readonly ErrorType values, the same way the built-in ones are declared:

public static class OrderErrorType
{
    public static readonly ErrorType OutOfStock = new(nameof(OutOfStock));
    public static readonly ErrorType PaymentDeclined = new(nameof(PaymentDeclined));
}

var error = new Error("Order.OutOfStock", "Item is out of stock", OrderErrorType.OutOfStock);

ASP.NET Core / Minimal APIs

Davish.Result.AspNetCore.Http converts a Result/Result<T> straight into a Minimal API IResult: a success maps to the corresponding 2xx, a failure maps to a ProblemDetails (or a validation problem, if Error.Fields is populated).

app.MapGet("/bookings/{id}", (int id, BookingService service) =>
    service.Find(id).ToOk());                              // 200 OK, or a problem result

app.MapPost("/bookings", (CreateBooking request, BookingService service) =>
    service.Create(request).ToCreated("GetBooking", b => new { id = b.Id }));  // 201 Created

app.MapDelete("/bookings/{id}", (int id, BookingService service) =>
    service.Delete(id).ToNoContent());                     // 204 No Content, or a problem result

Error type → status code mapping

Failures map to a status code by Error.Type. Built-in categories map as you'd expect (Validation/NullValue/BadRequest → 400, NotFound → 404, Unauthorized → 401, Forbidden → 403, Conflict → 409, ServiceUnavailable → 503, Unexpected and anything unregistered → 500). Register your own categories once at startup:

Davish.Result.ResultHttpOptions.Configure(v =>
{
    // v.UseDefault = false;   // opt out of the built-in mappings above

    v.CustomMap = new Dictionary<ErrorType, int>
    {
        [OrderErrorType.OutOfStock] = StatusCodes.Status409Conflict,
        [OrderErrorType.PaymentDeclined] = StatusCodes.Status402PaymentRequired,
    };
});

This is process-wide static configuration, applied immediately rather than resolved from a DI container — the same idea as configuring JsonSerializerOptions or Dapper's SqlMapper.Settings. Since ErrorType uses value equality, OrderErrorType.OutOfStock and any other ErrorType you build with the same name map to the same entry.