How expensive are exceptions in .NET? What exactly costs time when you throw and catch, what changed in .NET 9, how do try blocks affect performance when nothing is thrown, and what patterns (Try methods, result types, throw helpers) avoid exceptions on hot paths?

1. Anatomy of a throw in CoreCLR

throw new InvalidOperationException("...")
  1. newobj      -> allocate exception, run ctor (message formatting)
  2. throw       -> RaiseException path (since .NET 9: managed EH in System.Private.CoreLib)
  3. Pass 1      -> stack walk using unwind info; for each frame, consult EH table; run filters
  4. Pass 2      -> unwind to handler frame; run finally/fault funclets; record stack trace frames
  5. catch body  -> runs as a funclet with access to the parent frame

The stack walk uses unwind information generated by the JIT for each method (how to restore registers and find the caller frame). Each frame visited costs a lookup. Deep call stacks — typical with middleware pipelines, DI-heavy code and async — make exceptions more expensive.

Funclets: the JIT compiles catch, finally and filter blocks as separate small functions (funclets) called by the runtime during dispatch.

2. Why .NET 9's managed EH is faster

The old implementation went through the OS's structured exception handling (on Windows) or a C++ emulation (on Unix), with multiple transitions between native and managed code, locks and complex bookkeeping. NativeAOT already had a leaner managed implementation written in C#; .NET 9 adopted it for CoreCLR. Fewer transitions and simpler stack walking reduced throw/catch costs significantly. Semantics (two-pass, filters, finally ordering) are unchanged.

3. Stack trace capture costs

• Recording frames during unwind is relatively cheap (method handles + offsets).
• Formatting ex.StackTrace or ex.ToString() is expensive: resolving method names, generic arguments, and file/line numbers from PDBs. Logging every exception with full ToString() at high rates can dominate the cost.
• Reusing a pre-allocated exception instance (throwing the same object repeatedly) doesn't make it cheap — the stack is still captured — and it corrupts stack traces. Don't do it.

4. Async amplification

Controller -> Service -> Repository -> HttpClient
    await        await        await

If HttpClient throws, the exception is stored in the innermost task; each await up the chain calls ExceptionDispatchInfo.Throw, which performs a new throw in that frame (with the preserved trace appended). Three awaits ≈ three throw/catch cycles. Async-heavy failure paths are therefore more expensive than synchronous ones — another reason to avoid exceptions for expected outcomes in async APIs.

5. Try pattern design

Good Try methods:

• Return bool and use out for the result, annotated with [NotNullWhen(true)] / [MaybeNullWhen(false)] for nullable analysis.
• Never throw for the expected failure they represent (bad format, missing key) — but still throw for programming errors (null arguments).
• Come with a throwing counterpart (Parse/TryParse) for callers who treat failure as exceptional.
• For async, out isn't available; return a tuple, nullable, or result type: Task<(bool Found, Order? Order)> or Task<Order?>.

6. Result type performance

A readonly struct result (Result<T, TError>) costs a few bytes and no allocation; propagation is a branch. Libraries vary: some allocate error objects or use classes. For hot paths, prefer struct results and pre-allocated static error instances (static readonly Error NotFound = new(...)).

7. Measuring with BenchmarkDotNet

[MemoryDiagnoser]
public class ParseBench
{
    private const string Bad = "12x";

    [Benchmark] public int TryParse() => int.TryParse(Bad, out var v) ? v : -1;

    [Benchmark] public int ParseCatch()
    {
        try { return int.Parse(Bad); }
        catch (FormatException) { return -1; }
    }
}

Expect TryParse in nanoseconds with zero allocations, and ParseCatch in microseconds with hundreds of bytes allocated (exception object, message, stack trace data). Run on .NET 8 and .NET 9+ to see the managed EH improvement.

Try it yourself

1. Run the benchmark above on .NET 8 and .NET 10.
2. Measure throw/catch cost at stack depths of 1, 10 and 50 frames, and across 5 nested awaits.
3. Watch exception-count in dotnet-counters while sending invalid input to an endpoint that uses Parse vs TryParse.
4. Use DOTNET_LegacyExceptionHandling=1 on .NET 9+ to compare old and new EH performance.

using System.Diagnostics.CodeAnalysis;

// Bad: exceptions as control flow on a hot path
decimal ParseSlow(string s)
{
    try { return decimal.Parse(s, CultureInfo.InvariantCulture); }
    catch (FormatException) { return 0m; }            // thrown for every blank field
}

// Good: Try pattern
decimal ParseFast(string s) =>
    decimal.TryParse(s, NumberStyles.Number, CultureInfo.InvariantCulture, out var d) ? d : 0m;

// Result type for business outcomes
public readonly record struct Result<T>(T? Value, string? Error)
{
    public bool IsSuccess => Error is null;
    public static Result<T> Ok(T value) => new(value, null);
    public static Result<T> Fail(string error) => new(default, error);
}

public Result<Payment> Withdraw(Account acc, decimal amount) =>
    acc.Balance < amount
        ? Result<Payment>.Fail("insufficient-funds")      // expected outcome, no throw
        : Result<Payment>.Ok(acc.Debit(amount));

// Throw helper keeps the hot method small
public sealed class RingBuffer<T>(int capacity)
{
    private readonly T[] _items = new T[capacity];
    private int _count;

    public T this[int index]
    {
        get
        {
            if ((uint)index >= (uint)_count) ThrowIndex(index);
            return _items[index];
        }
    }

    [DoesNotReturn]
    private static void ThrowIndex(int index) =>
        throw new ArgumentOutOfRangeException(nameof(index), index, "Index outside the buffer.");
}