One of the important changes to programming style that .NET brought to developers is the use of exceptions as the primary method of error handling.
This is not a revolutionary approach since exceptions have been actively used in various programming languages, but for a generation of programmers trained
on traditional Windows and COM APIs, it did require change of their habits. No more
HRESULT analysis, no more struggling with
no more traversing of records obtained through the
IErrorInfo interface. Just throw, try, catch, and finally.
Since the initial release of .NET, there’s been a discussion on whether Microsoft has gone too far with abandoning error codes. In this article, I will not go into
arguments on that matter. Larry Osterman from Microsoft in his blog articles "Exceptions as repackaged
error codes" and "Error Code Paradigms" covers some aspects of this discussion.
An excellent set of guidelines was compiled by Krzysztof Cwalina. Of course, Microsoft also published
various recommendations on exceptions' best practices, including
"Error Raising and Handling Guidelines".
So I will not try to answer the question "to throw or not to throw?". Honestly, if I knew the definitive answer of such a question, I would not have spent time to write programs
just to study exceptions behavior. But I don’t. So I felt I had to thoroughly investigate various aspects of using exceptions. And one of the most important aspects is their performance.
Exceptions cost. Throwing them without understanding how much they cost may have a negative impact on your application. In this article, I will present performance
results measured using different scenarios, including throwing exceptions from methods of different complexity, within a single AppDomain and across domains.
To collect performance measurements, I have written a small .NET Windows Forms application. Using this application, it is possible to specify the job type,
how to throw (or not throw) an exception, and select a time interval while the selected job is executed. When the time expires, the application shows the job execution count.
Its main screen is shown in figure 1.
Figure 1. Exception performance benchmark application.
There are five job types that can be executed:
- Empty - As it’s easy to guess, an empty method.
- String processing - A string "The quick brown fox jumps over the lazy dog" is split into words and each word is then uppercased.
- File access - The application reads the contents of every file in the current directory.
- Database - A SQL statement "
SELECT * FROM Products" is executed using SQL Server ADO.NET provider and Northwind database.
- Complex - A combination of string (8 times), file (4 times), and database (2 times) operations. This is a simulation of a simple business
logic operation, although a very light one, since both file and database operations are read-only.
In addition, the application defines five modes of exceptions:
- No exception - Plain job execution.
- Catch without exception - Method is executed inside a
catch block, but no exception is thrown.
- Throw - A single exception is thrown and caught after the job is executed.
- Rethrow original - An exception is thrown, caught, and re-thrown.
- Rethrow new - An exception is thrown, caught, and then a new exception is thrown with the original one set as an inner exception.
Since exceptions drag quite a lot of information, in case the method is executed across
AppDomains and results in exception, it incurs considerable
extra costs related to its serialization. To measure such costs, I have added the possibility to execute selected jobs in a separate
Below I present the results of application execution on my Dell Latitude D800 with Pentium M 1.70 GHz. Every test was executed using a 1 second interval.
The perfect world: no exceptions
To begin with our benchmarking, we need to gather reference data: how fast is the code when no exceptions are thrown? Table 1 shows this information:
|Catch without exception
Table 1. No exceptions thrown (executions per second).
It is too early to make conclusions at this stage, but two things can be observed. First, there is no cost in a
block (might sound obvious but I’ve heard arguments that low level code should avoid
catch blocks for performance reasons).
Second, with a difference of 100,000 times between empty and complex operations, it does not make much sense to talk about absolute costs of using exceptions.
They must be analyzed in the context of operations.
The real world: exceptions added
Now let’s look at how much the use of an exception costs. The results are shown in table 2:
Table 2. Exceptions thrown (executions per second).
Here we can see that exceptions do not present a significant performance threat for operations that are more complex than simple calculation algorithms.
Only primitive string processing was affected by raised exceptions. As soon as the method involves accessing files or databases (and majority of them do),
the cost of exceptions become really marginal.
Another observation is that wrapping an exception in a new one does not really affect the performance compared to re-throwing an original one,
so you should not be afraid of doing this just for performance reasons.
The heavy world: sending exceptions across application domains
If you recognize exceptions as the sole method of propagating error information and replace them with numerical traditional error codes, you should be aware
of the associated costs of cross-domain exception marshalling. Every exception is a large packet of information that includes even a callstack. When being sent
across threads or application domains, this packet is serialized and de-serialized, and of course this comes at a price. Table 3 shows these costs:
Table 3. Exceptions thrown across domains (executions per second).
As you can see, application domains are performance killers by themselves. An empty method is executed with a speed that is more than 400 times slower than execution
within the same domain! Think twice before splitting your components between different domains. However, sometimes this is an only option, and in such cases, exceptions
add even more to the performance costs. For simple computational tasks, exception handling will use more than 90% of the processing time. Even for file access
operations, cross-domain exception marshalling slows down the execution to almost half the speed. But more complex business logic operations can still afford
to throw exceptions even in multiple domain environments.
Exception handling is much more than its performance aspects. Here, I have not touched such topics as whether exceptions should be thrown only in abnormal
situations or they should cover all unsuccessful operational states. Perhaps the only conclusion I can draw from the presented results is that for everything
but simple computational algorithms, exceptions do not have a big impact on performance, at least not big enough to make a design decision regarding exceptions based
mostly on performance reasons. You should carefully apply the guidelines presented in the referenced articles and in case performance is of high concern, implement
additional methods that will help avoid unnecessary raising of exceptions (Tester-Doer and Try-Parse patterns in Krzysztof Cwalina’s article). But in general, exceptions
will fit in most architectures without a noticeable performance impact.
- Exception Throwing Guidelines by Krzysztof Cwalina
- Exceptions as repackaged error codes by Larry Osterman
- Error Code Paradigms by Larry Osterman
- Error Raising and Handling Guidelines by Microsoft