Introduction

The try/finally construct in C# guarantees that cleanup code in the finally block executes regardless of whether an exception is thrown. Developers sometimes worry about the performance cost of wrapping code in try/finally, especially in hot loops or performance-critical paths. In practice, the .NET JIT compiler applies optimizations that make the overhead negligible when no exception is thrown.

How try/finally Works at the JIT Level

When the JIT compiler encounters a try/finally block, it generates metadata that maps the protected region of code to the corresponding finally handler. During normal execution, the CPU runs through the try block instructions without any additional branching or checking. The runtime only consults the exception-handling tables when an exception actually occurs.

1public int ComputeSum(int[] values)
2{
3    int sum = 0;
4    try
5    {
6        for (int i = 0; i < values.Length; i++)
7        {
8            sum += values[i];
9        }
10    }
11    finally
12    {
13        // cleanup logic here
14        Console.WriteLine("Done");
15    }
16    return sum;
17}

In the happy path where no exception is thrown, the generated machine code for the try block is nearly identical to what it would be without the try/finally wrapper. The JIT still inlines methods, eliminates bounds checks, and applies other optimizations within the try block.

Measuring the Overhead with BenchmarkDotNet

You can measure the actual overhead using BenchmarkDotNet to compare a method with and without try/finally.

1using BenchmarkDotNet.Attributes;
2using BenchmarkDotNet.Running;
3
4[MemoryDiagnoser]
5public class TryFinallyBenchmark
6{
7    private int[] data;
8
9    [GlobalSetup]
10    public void Setup()
11    {
12        data = new int[1000];
13        for (int i = 0; i < data.Length; i++)
14            data[i] = i;
15    }
16
17    [Benchmark(Baseline = true)]
18    public int WithoutTryFinally()
19    {
20        int sum = 0;
21        for (int i = 0; i < data.Length; i++)
22            sum += data[i];
23        return sum;
24    }
25
26    [Benchmark]
27    public int WithTryFinally()
28    {
29        int sum = 0;
30        try
31        {
32            for (int i = 0; i < data.Length; i++)
33                sum += data[i];
34        }
35        finally
36        {
37            // empty finally block
38        }
39        return sum;
40    }
41}

In typical results, the two methods produce nearly identical timings. The difference is within the margin of measurement noise, confirming that try/finally with no exception has effectively zero runtime cost.

Where try/finally Does Have Cost

The overhead becomes real in two scenarios. First, when an exception is actually thrown, the runtime must walk the stack, find the matching handler, and execute the finally block. This process is orders of magnitude slower than normal execution.

1// This is expensive because the exception is thrown every iteration
2for (int i = 0; i < 10000; i++)
3{
4    try
5    {
6        throw new InvalidOperationException("error");
7    }
8    catch (InvalidOperationException)
9    {
10        // handle
11    }
12    finally
13    {
14        // cleanup
15    }
16}

Second, the presence of a try/finally block can inhibit certain JIT optimizations. For example, the JIT may not inline a method that contains exception-handling constructs, and it may limit register allocation optimizations within the protected region.

1// The JIT may skip inlining this method due to the try/finally
2[MethodImpl(MethodImplOptions.AggressiveInlining)]
3public int SmallMethod(int x)
4{
5    try
6    {
7        return x * 2;
8    }
9    finally
10    {
11        // prevents inlining in older .NET versions
12    }
13}

In modern .NET (6 and later), the JIT has improved significantly and can inline methods with simple try/finally blocks in many cases.

try/finally vs the using Statement

The using statement in C# compiles down to a try/finally block. They have identical performance characteristics.

1// These two are equivalent
2using (var stream = new FileStream("file.txt", FileMode.Open))
3{
4    // read from stream
5}
6
7// Compiler generates:
8FileStream stream = new FileStream("file.txt", FileMode.Open);
9try
10{
11    // read from stream
12}
13finally
14{
15    if (stream != null)
16        ((IDisposable)stream).Dispose();
17}

The using declaration syntax introduced in C# 8 also generates the same try/finally pattern, with the finally block at the end of the enclosing scope.

1public void ReadFile()
2{
3    using var stream = new FileStream("file.txt", FileMode.Open);
4    // read from stream
5    // Dispose is called in a finally block at method end
6}

Since using is just syntactic sugar over try/finally, there is no reason to avoid using for performance reasons.

When the Overhead Matters

In the vast majority of applications, the overhead of try/finally is not measurable. However, there are narrow scenarios where you should be aware of it.

1// Tight numerical loop - avoid try/finally inside the loop
2public double ComputeAverage(double[] values)
3{
4    double sum = 0;
5    // Place try/finally outside the loop, not inside
6    try
7    {
8        for (int i = 0; i < values.Length; i++)
9        {
10            sum += values[i];
11        }
12    }
13    finally
14    {
15        // cleanup once, not per iteration
16    }
17    return sum / values.Length;
18}

In micro-benchmarks running billions of iterations, placing try/finally inside a tight loop rather than outside it can show a small but consistent difference because it may affect the JIT's ability to optimize the loop body. The solution is to structure your code so that try/finally wraps the loop rather than being inside it.

Common Pitfalls

• Avoiding try/finally for performance reasons: The overhead on the happy path is effectively zero. Skipping try/finally to save performance leads to resource leaks that cause far worse problems than any micro-optimization could solve.
• Throwing exceptions in normal control flow: The real cost of exception handling comes from throwing and catching exceptions, not from the try/finally structure itself. Never use exceptions for expected control flow like loop termination or validation.
• Placing try/finally inside tight loops: While the overhead is small, placing a try/finally inside a loop that runs millions of times can prevent loop optimizations. Move the try/finally outside the loop when possible.
• Assuming using is slower than manual cleanup: The using statement compiles to the same try/finally pattern. Manual Dispose() calls without using risk missing cleanup on exceptions and offer no performance benefit.
• Ignoring JIT version differences: Older .NET Framework JIT compilers are more conservative about optimizing around try/finally than modern .NET JIT. If you are targeting .NET Framework 4.x, test performance-critical paths with benchmarks rather than assuming modern JIT behavior.

Summary

• The try/finally construct has effectively zero overhead when no exception is thrown because the JIT generates normal code with exception-handler metadata consulted only on exceptions.
• The real cost comes from actually throwing exceptions, which involves stack walking and handler lookup.
• The using statement compiles to try/finally and has identical performance characteristics.
• Place try/finally outside tight loops rather than inside them to avoid inhibiting loop optimizations.
• Always prefer correct resource cleanup with try/finally or using over micro-optimizations that risk resource leaks.