Try-catch speeds up code? Analyzing the paradox and errors in C#

How can a try-catch block "speed up" your C# code? Debunking myths and reality

Imagine a situation: you write C# code, run it, and suddenly notice that adding a try-catch block makes the program run faster. Sounds like magic, or conversely, like a beginner's gross mistake? In fact, this question has gathered thousands of views on Stack Overflow. And the answer will surprise you: try-catch itself does not speed up code, but it can drastically change the behavior of the JIT compiler, which sometimes leads to unexpected performance gains. Let's analyze this paradox, and along the way — the top errors when working with exceptions that can turn your fast code into a sluggish mess.

Why does the illusion of speedup occur?

The question on Stack Overflow went something like this: "I wrote two methods: one with try-catch, the other without. The method with try-catch runs faster. Why?"

The key point is the JIT compiler (Just-In-Time). When C# code is compiled into IL and then into machine code, JIT can apply various optimizations. If there is no explicit exception thrown inside the try block, the compiler may disable some optimizations (e.g., method inlining or instruction reordering) to ensure correct stack behavior in case an exception occurs. This sounds bad, but in some rare scenarios (especially in older versions of .NET Framework), JIT could behave counterintuitively: code without try-catch underwent aggressive optimization that broke the CPU cache, while code with try-catch did not. As a result, the second option ran faster.

// Example that can be misleading\npublic int SumWithoutTry(int[] array)\n{\n    int sum = 0;\n    for (int i = 0; i < array.Length; i++) // No try-catch\n    {\n        sum += array[i];\n    }\n    return sum;\n}\n\npublic int SumWithTry(int[] array)\n{\n    int sum = 0;\n    try\n    {\n        for (int i = 0; i < array.Length; i++)\n        {\n            sum += array[i];\n        }\n    }\n    catch (Exception) { /* do nothing */ }\n    return sum;\n}\n

In modern versions of .NET (Core 3.0+, .NET 5/6/7/8), this effect has practically disappeared. JIT has become smarter, and try-catch does not affect speed in such simple loops. But the very existence of this question is an excellent reason to talk about how to work with exceptions correctly.

Top errors when using try-catch in C#

Now that we've debunked the myth, let's move on to real problems. Here is a list of the most common errors that actually slow down your code and make it less reliable.

1. Using exceptions for flow control

This is a classic. Programmers coming from languages with "lazy" error handling sometimes write like this:

// BAD\ntry\n{\n    int.Parse(inputString);\n}\ncatch (FormatException)\n{\n    // If parsing fails — use default value\n    inputString = "0";\n}\n

The problem is that throwing an exception is a very expensive operation. JIT must build the call stack, create the exception object, and traverse the catch blocks. Instead, use TryParse:

// GOOD\nif (int.TryParse(inputString, out int result))\n{\n    // work with result\n}\nelse\n{\n    // handle error without exception\n}\n

Conclusion: Never use try-catch as a replacement for a conditional statement. Exceptions are for exceptional situations, not for normal logic.

2. Empty catch block

"Swallowing" an exception is one of the worst practices: