How do try, catch and finally work in C#? In what order are catch blocks checked, when does finally run (and when does it not), and how do using statements relate to try/finally?

1. How the CLR finds a handler: two-pass exception handling

.NET uses a two-pass model (like Windows SEH):

1. First pass (search): starting from the throwing frame, the runtime walks up the stack looking for a matching catch clause, evaluating exception filters (when) along the way. No stack frames are unwound yet, and no finally blocks run.
2. Second pass (unwind): once a handler is found, the runtime unwinds frames from the throw point up to the handler, running finally and fault blocks in each frame, then executes the catch block.

This is why exception filters run before inner finally blocks, and why a filter sees the stack exactly as it was at the throw — useful for diagnostics and crash dumps.

.NET 9 replaced the runtime's C++ exception-handling implementation with a managed one (ported from NativeAOT), making throw/catch roughly 2–4× faster, but the semantics are the same.

2. Exception handling tables in IL

Each method has an exception handling table listing protected regions (try ranges) and their handlers:

.try IL_0000 to IL_0020 catch System.IO.IOException handler IL_0020 to IL_0030
.try IL_0000 to IL_0030 finally handler IL_0030 to IL_0038

The C# compiler nests try/catch/finally as try { try { } catch { } } finally { }. catch ... when becomes a filter block (filter handler) that returns a decision. Because handlers are described by tables, a try block with no exception costs essentially nothing at run time — "zero-cost" exception handling. The cost is paid only when something is thrown.

3. Interaction with return

static int Get()
{
    int x = 1;
    try { return x; }          // return value (1) is captured here
    finally { x = 2; }         // runs, but doesn't change the returned value
}

The return value is stored in a temporary before finally runs. You cannot return from inside a finally in C# (CS0157), which prevents the Java pitfall where a finally return swallows exceptions.

4. Exceptions thrown inside finally or catch

If a finally block throws while an exception is already propagating, the new exception replaces the original — the original is lost unless captured. Same for a catch block that throws a different exception without passing the original as InnerException. Defensive patterns: keep finally blocks simple, make Dispose non-throwing, and when wrapping, pass the inner exception.

5. Async methods

In an async method, try/catch/finally work across await: the compiler moves the bodies into the state machine's MoveNext, and exceptions from awaited tasks are rethrown at the await point (the first inner exception for faulted tasks). finally blocks run when the method's execution leaves the try — which may be much later and on a different thread. Exceptions thrown in an async Task method are stored in the returned Task; in async void methods they're raised on the SynchronizationContext or thread pool and typically crash the process.

6. using details

• For a struct implementing IDisposable, using calls Dispose without boxing (constrained call).
• Pattern-based disposal: ref structs with a Dispose() method can be used in using without implementing the interface.
• using var scopes end at the enclosing block, so the resource lives until then — sometimes longer than intended; use a block-scoped using (...) { } when you need earlier release (e.g. before a long computation).
• Multiple using declarations are disposed in reverse order.

7. What not to do in catch

• Catch exceptions you can't handle meaningfully (log-and-rethrow at every layer creates duplicate logs).
• Catch Exception in library code and swallow it.
• Use exceptions for normal control flow (int.Parse in a try instead of TryParse).

Try it yourself

1. Write nested try/finally blocks across three methods with Console.WriteLine in each finally and filter, throw from the innermost, and observe the order (filters run before finallys).
2. Return a value from try and modify it in finally.
3. Call Environment.FailFast inside a try with a finally and observe that the finally doesn't run.
4. Throw from a Dispose method while another exception is propagating and see which one reaches the catch.

private static readonly SemaphoreSlim Gate = new(1, 1);

public async Task<int> ImportAsync(string path, CancellationToken ct)
{
    await Gate.WaitAsync(ct);
    try
    {
        await using var stream = File.OpenRead(path);      // try/finally + DisposeAsync
        using var reader = new StreamReader(stream);
        return await ParseAsync(reader, ct);
    }
    catch (FileNotFoundException ex)                       // most specific first
    {
        logger.LogWarning(ex, "Import file {Path} missing", path);
        return 0;                                          // fallback is a real decision
    }
    catch (IOException ex)                                 // more general
    {
        throw new ImportFailedException(path, ex);         // add context, keep inner
    }
    finally
    {
        Gate.Release();                                    // runs on success, return and exceptions
    }
}