Better Error Handling in C# with Result Types

Exceptions are slow, cumbersome, and often result in unexpected behavior. Even the official Microsoft documentation recommends limiting your use of exceptions, imagine that. Most of the time, you want to handle both success and failure cases without allowing exceptions to propagate. You might wonder, "If I won't use exceptions, how can I tell the caller function that something went wrong?". This is where the Result type comes in.

The Result Type

When our function needs to represent two states - a happy path and a failure path - we can model it with a generic type Result<T, E> where T represents the value and E represents the error.

public async Result<PaymentReceipt, PaymentError> ProcessPayment(PaymentRequest request) {
    if (request.Amount <= 0) {
        return new PaymentError("Amount must be positive");
    }
    
    try {
        PaymentReceipt receipt = await paymentGateway.ChargeAsync(
            request.CardToken, 
            request.Amount,
            request.Currency
        );
            
        if (receipt.Status != "succeeded") {
            return new PaymentError($"Payment failed: {receipt.Reason}");
        }
        
        return receipt;
    } catch (ApiException ex) {
        // network or service errors
        return new PaymentError($"Payment service error: {ex.Message}");
    }
}

[HttpPost]
public async Task<IActionResult> SubmitPayment(PaymentRequest request)
{
    if (!ModelState.IsValid) {
        return BadRequest(ModelState);
    }
    
    Result<PaymentReceipt, PaymentError> result = await ProcessPayment(request);
    
    return result.Match<IActionResult>(
        receipt => Ok(new { Status = "success", ReceiptId = receipt.Id }),
        error => BadRequest(new { Status = "failure", Message = error.Message })
    );
}

If you don't want to return strings for errors, you can define custom classes/structs or even use existing Exception types. Returning exceptions is fine, throwing them is what's costly

Result Struct

public readonly struct Result<T, E> {
    private readonly bool _success;
    public readonly T Value;
    public readonly E Error;
    
    private Result(T v, E e, bool success)
    {
        Value = v;
        Error = e;
        _success = success;
    }
    
    public bool IsOk => _success;
    
    public static Result<T, E> Ok(T v)
    {
        return new(v, default(E), true);
    }
    
    public static Result<T, E> Err(E e)
    {
        return new(default(T), e, false);
    }
    
    public static implicit operator Result<T, E>(T v) => new(v, default(E), true);
    public static implicit operator Result<T, E>(E e) => new(default(T), e, false);
    
    public R Match<R>(
            Func<T, R> success,
            Func<E, R> failure) =>
        _success ? success(Value) : failure(Error);
}

The implicit operators allow you to return a value or error directly

For example,

return new PaymentError("Amount must be positive") 

can be used instead of

return new Result<PaymentReceipt, PaymentError>.Err(new PaymentError("Amount must be positive"))

It will automatically convert it to a result type for you

Quick Benchmark

I benchmarked the performance difference between returning a Result type versus throwing an exception. The benchmark compares identical functions failing at different rates: 0%, 30%, 50%, and 100% of the time:

What we care about here is the mean. You can see that returning the result directly and matching outperforms exception handling as exceptions get thrown more often. In reality, your function will probably not throw exceptions 50% of the time but this is just a benchmark to illustrate how slow exceptions can be if used often.

Benchmark Code

public class ErrorHandlingBenchmark
{
    [Params(0, 30, 50, 100)]
    public int FailurePercentage { get; set; }
    
    private const int IterationCount = 100;
    
    [Benchmark]
    public int[] BenchmarkResultType()
    {
        int[] results = new int[IterationCount];
        
        for (int i = 0; i < IterationCount; i++)
        {
            bool shouldFail = i < FailurePercentage;
            
            results[i] = CalculateWithResultType(shouldFail)
                .Match(
                    success => success + 10, 
                    error => 0
                );
        }
        
        return results;
    }
    
    [Benchmark]
    public int[] BenchmarkExceptionHandling()
    {
        int[] results = new int[IterationCount];
        
        for (int i = 0; i < IterationCount; i++)
        {
            bool shouldFail = i < FailurePercentage;
            
            try
            {
                results[i] = CalculateWithException(shouldFail) + 10;
            }
            catch (Exception)
            {
                results[i] = 0;
            }
        }
        
        return results;
    }
    
    private Result<int, string> CalculateWithResultType(bool shouldFail)
    {
        if (shouldFail)
        {
            return "Operation failed";
        }
        
        return 1;
    }
    
    private int CalculateWithException(bool shouldFail)
    {
        if (shouldFail)
        {
            throw new InvalidOperationException("exception");
        }
        
        return 1;
    }
}