Processing exceptions in any language is expensive. The process of capturing an exception and rolling it into a package that can be processed by code requires a stack walk—basically looking back through the history of what has happened—and that requires a lot of processing time to complete. In .NET software development we sometimes talk about boxing and unboxing of variables and how that can consume a great deal of time in a program—and it can. However, the amount of time necessary to process an exception dwarfs the time necessary to box and unbox a variable. (If you want to know more about boxing and unboxing you can read about it in the article “Boxing and Unboxing of Value Types in C#” on CodeGuru.)

Despite the fact that exceptions are expensive to process they are positively a great thing for debugging applications and making software more reliable. The challenge is when exceptions are used incorrectly; specifically, when they are used to respond to normal conditions instead of exceptional conditions. Generally when this happens the layers of software above the layer generating the exception start “eating” the exception—because nothing is wrong (more on eating exceptions in a moment)—and manually return to normal program flow. This, however, leads to subtle performance issues that are difficult to find. Running a profiler on the code can show where performance is being impacted, however, there’s a quicker and simpler way to find performance problems like these—or rule out exceptions as a potential cause of performance issues.

Using first chance exceptions in the debugger is a way to ferret out these hidden exceptions that your application is generating so that you can go back and prevent them from happening in the first place. The more exceptions you prevent, the faster your application will run. First chance exceptions are exposed via Visual Studio and can be leveraged in any language that compiles to the CLR.

http://www.devx.com/dotnet/Article/31414/