Introduction

In .NET, exceptions are designed for exceptional situations, not routine branching. The important performance rule is simple: having try and catch blocks is usually cheap, but actually throwing exceptions is expensive enough that you should avoid using them for normal control flow.

Where the Cost Comes From

When code throws an exception, the runtime has to do much more work than a normal conditional branch:

• allocate and initialize an exception object
• capture stack information
• unwind the stack until it finds a matching handler
• disrupt branch prediction and optimized hot-path execution

That means the real cost is concentrated in the throw, not in the existence of a surrounding try block.

Fast Path Versus Failure Path

This distinction explains why code like this is fine:

1try
2{
3    ProcessRequest(request);
4}
5catch (IOException ex)
6{
7    logger.LogError(ex, "I/O failure");
8}

If ProcessRequest usually succeeds, the fast path is still reasonable.

What you want to avoid is code that treats exceptions as an expected branch:

1int ParsePort(string text)
2{
3    try
4    {
5        return int.Parse(text);
6    }
7    catch
8    {
9        return 0;
10    }
11}

For user input, int.TryParse is the right API because invalid input is expected, not exceptional.

1int ParsePort(string text)
2{
3    return int.TryParse(text, out var port) ? port : 0;
4}

A Small Benchmark

The following example shows the difference in shape. Exact times vary by machine and runtime, but the exception path will be dramatically slower.

1using System;
2using System.Diagnostics;
3
4class Program
5{
6    static void Main()
7    {
8        const int iterations = 100_000;
9
10        var sw = Stopwatch.StartNew();
11        for (int i = 0; i < iterations; i++)
12        {
13            int.TryParse("bad", out _);
14        }
15        sw.Stop();
16        Console.WriteLine($"TryParse: {sw.ElapsedMilliseconds} ms");
17
18        sw.Restart();
19        for (int i = 0; i < iterations; i++)
20        {
21            try
22            {
23                int.Parse("bad");
24            }
25            catch (FormatException)
26            {
27            }
28        }
29        sw.Stop();
30        Console.WriteLine($"Parse with exceptions: {sw.ElapsedMilliseconds} ms");
31    }
32}

The point of this benchmark is not the exact ratio. The point is that repeated throws in a hot loop are obviously the wrong shape for performance-sensitive code.

When Exceptions Are Still Correct

Performance advice should not turn into bad design advice. Exceptions still make sense when a failure is truly abnormal or when pushing explicit error codes through every call layer would make the program less correct.

Examples:

• opening a required config file that should always exist
• receiving impossible state from a trusted component
• failing a database transaction in a way the caller must not ignore

In those cases, clarity and correctness matter more than shaving a branch.

Practical Guidelines

Use guard methods such as TryParse, TryGetValue, and validation checks when failure is part of normal behavior. Reserve exceptions for contract violations, unexpected runtime failures, and unrecoverable paths.

Also profile before making sweeping changes. If exceptions are rare, they may not matter in the total runtime. If they are frequent, they are usually symptoms of a poor API choice or a mis-modeled fast path.

Common Pitfalls

The most common mistake is benchmarking only one throw and then drawing broad conclusions. Exception overhead becomes most visible when throws happen repeatedly in hot paths.

Another mistake is replacing all exceptions with return codes just for speed. That can make error handling silent and brittle. The goal is not "no exceptions ever." The goal is "no exceptions for expected outcomes."

A third issue is catching overly broad exceptions such as Exception and swallowing them. That hides bugs and can make performance analysis harder because the system keeps recovering from problems it should surface.

Summary

• 'try and catch are usually cheap until an exception is actually thrown.'
• Throwing exceptions is much slower than ordinary branching.
• Use TryParse-style APIs when failure is expected and common.
• Keep exceptions for exceptional failures and correctness boundaries.
• Profile real workloads before turning error-handling style into a micro-optimization exercise.