Do you use the result pattern?

Using exceptions for control flow in .NET applications leads to poor performance, unclear code intent, and makes it difficult to distinguish between expected failures and truly exceptional circumstances. The Result pattern provides a clean, explicit way to handle errors without the overhead and complexity of exceptions.

The Problem with Exceptions

Traditional error handling relies heavily on exceptions, even for expected failure scenarios like validation errors or "not found" cases. This approach has several drawbacks:

• Performance overhead - Throwing and catching exceptions is expensive
• Unclear intent - It's not obvious which exceptions a method might throw
• Control flow complexity - Multiple catch blocks make code hard to follow
• Mixing concerns - Expected failures are treated the same as unexpected errors

public class UserService
{
    public User GetUserById(int id)
    {
        var user = _repository.FindById(id);
        
        if (user == null)
            throw new NotFoundException($"User {id} not found");
            
        if (!user.IsActive)
            throw new InvalidOperationException("User is not active");
            
        return user;
    }
}

// Calling code
try
{
    var user = userService.GetUserById(123);
    // Process user
}
catch (NotFoundException ex)
{
    // Handle not found
}
catch (InvalidOperationException ex)
{
    // Handle invalid operation
}
catch (Exception ex)
{
    // Handle unexpected errors
}

❌ Figure: Bad example - Using exceptions for expected failures leads to performance issues and unclear code

The Result Pattern Solution

The Result pattern represents the outcome of an operation as a return value, explicitly indicating success or failure with relevant error information. This makes error handling first-class, improves performance, and clarifies code intent.

public class UserService
{
    public ErrorOr<User> GetUserById(int id)
    {
        var user = _repository.FindById(id);
        
        if (user == null)
            return Error.NotFound(description: $"User {id} not found");
            
        if (!user.IsActive)
            return Error.Validation(description: "User is not active");
            
        return user;
    }
}

// Calling code
var result = userService.GetUserById(123);

return result.Match(
    user => Ok(user),
    errors => Problem(errors)
);

✅ Figure: Good example - Using the Result pattern makes error handling explicit and performant

Benefits of the Result pattern:

• ✅ Explicit error handling - Return type clearly indicates the operation can fail
• ✅ Better performance - No exception overhead for expected failures
• ✅ Type safety - Compiler ensures errors are handled
• ✅ Clear intent - Success and failure paths are obvious
• ✅ Composability - Results can be chained and transformed easily

Comparing .NET Result Pattern Libraries

Several excellent libraries implement the Result pattern in .NET. Here's a comparison of the most popular options:

Why ErrorOr is Recommended

ErrorOr is the recommended choice for most .NET projects

ErrorOr, created by Amichai Mantinband, offers the best balance of simplicity, functionality, and modern C# patterns:

• Simple, fluent API - Easy to learn and use with minimal boilerplate
• Excellent pattern matching - Works beautifully with C# pattern matching
• Discriminated union approach - Type-safe and compiler-enforced error handling
• Lightweight - Minimal dependencies and overhead
• Well-maintained - Active development and community support
• **Perfect for Clean Architecture & VSA **- Ideal for CQRS, MediatR, and DDD patterns
• **Built in result variations **- These help the domain communicate richer errors with calling layers (e.g. NotFound, Conflict, etc)

Getting Started with ErrorOr

Installation

dotnet add package ErrorOr

Basic Usage

using ErrorOr;

public class ProductService
{
    public ErrorOr<Product> CreateProduct(string name, decimal price)
    {
        // Validation
        if (string.IsNullOrWhiteSpace(name))
            return Error.Validation(description: "Product name is required");
            
        if (price <= 0)
            return Error.Validation(description: "Price must be greater than zero");
            
        // Business logic
        var product = new Product { Name = name, Price = price };
        _repository.Add(product);
        
        return product;
    }
}

// In your controller/endpoint
[HttpPost]
public IActionResult CreateProduct(CreateProductRequest request)
{
    var result = _productService.CreateProduct(request.Name, request.Price);
    
    return result.Match(
        product => Ok(product),
        errors => Problem(errors)
    );
}

✅ Figure: ErrorOr makes it easy to handle success and failure cases with pattern matching

When to Use Result Pattern vs Exceptions

Use the Result pattern for:

• ✅ Expected failures (validation, not found, business rule violations)
• ✅ Control flow in business logic
• ✅ Operations that commonly fail
• ✅ Public API boundaries

Use exceptions for:

• ⚠️ Truly exceptional circumstances (out of memory, network failures)
• ⚠️ Programming errors (null reference, index out of bounds)
• ⚠️ Infrastructure failures
• ⚠️ Unrecoverable errors

Learn more:

• ErrorOr on GitHub
• FluentResults on GitHub
• Ardalis.Result on GitHub