Performance Issues with exception handling
An often discussed topic in the developer world is the performance of handling exceptions. Some argue that exception handling is too expensive. Yes, there is a performance hit when handling exceptions, but when you look at what you get out of exception handling, in my opinion, that is much more important and outweighs the fact that there is going to be a performance hit associated with the exception handling.
A big plus in the world of .Net and exception handling is the garbage collector. Managed code has its objects stored in the managed heap, and the garbage collector takes care of the managed heap for us. When we create objects in our code and then throw an exception, we know that the GC is going to eventually clean up those objects. Managed code compilers don't have to keep track of this information at compile time like some other compilers, and this helps out with the performance. The wonderful little Finally block in managed code allows us to clean up some of these resources ourselves, even. An unmanaged code compiler (unmanaged C++ is the best example) has to know what's going on with its objects. When an exception occurs, all the deconstructors for these objects must be called for all the objects that were created successfully prior to the exception. There is a lot of tracking going on there with the compiler, and it increases code size and creates a performance hit in order to handle all of this in unmanaged code. Managed code, thankfully, the compiler doesn't care anymore. Managed code compilers know that big brother GC will clean up any mess that gets made along the way, making our code smaller and probably (I haven't tested this yet, and honestly probably won't) performing better when an exception is thrown, given certain circumstances, than the same code written and compiled with an unmanaged code compiler. The reason I probably won't test this is because the JIT and your platform can greatly impact the performance of exception handling. Code JITted for an Alpha processor is going to perform differently than code produced for an x86 processor, and I don't have the resources to do all the testing necessary to get solid numbers. Just take my word for it, exception handling is worth any performance hit you might incur, so implement exception handling.
What's the alternative to exception handling for you skeptics? You write code to check the input values and return values of each one of your methods and pass a return value back up to the caller. This in itself is quite a performance hit, not to mention a coding and maintenance nightmare due to all the extra code that has to be written to do this. You also introduce more possible points of failure, which quite honestly, you need to wrap in Try blocks to handle an exception that may occur in your custom i-don't-like-exceptions-they-are-too-expensive-i'm-going-to-do-it-my-way code. Why do all that when it can be handled with a simple Try..Catch..Finally...End Try? I would have thought this argument would have gone away by now, but I still hear and see it lingering around. In my opinion, use exception handling and use it out the wazoo, where appropriate. What you gain is far better and more important than what you lose.
Exception handling is a very deep and diverse topic in managed code. Most managed code books probably have an entire chapter devoted just to exceptions. I encourage you to pick up one and read about them, if you haven't done so already.