"In my ad-hoc testing using C#, I discovered that there is some truth to both of the statements above. Outside the debugger, throwing exceptions was on average 6 times slower than passing arguments. But inside the debugger, throwing exceptions was on average 65 times slower than passing arguments. This was a looping test throwing an exception only one level deep, so real-life performance of exceptions multiple levels deep and scattered across a program would be even slower."

http://www.devtopics.com/exceptions-are-for-exceptions

If you think about what actually happens at the low level, it's quite obvious that throwing exceptions involves considerable overhead – especially if the catch is many stack frames below the one throwing one. However, proctecting code in a try-block doesn't cost anything as long as exceptions don't occur. So basically we should catch them when we can't handle them, and otherwise not.

Many programmers write code with lots of catch blocks and few if any throw statements, and then fail to actually *handle* the exceptions in the catch blocks. I've even come across quite a few empty catch blocks, which of course serves no purpose other than hide the fact that things went haywire, causing other things to go haywire elsewhere and making it exponentially more difficult to figure out what happened – or, in especially unlucky cases, in no errors the system is aware of at all, but rather corrupted data and false results. It' great for financial reporting applications…

I hope you take a gander and add your thoughts.

http://www.pchenry.com/Home/tabid/36/EntryID/123/Default.aspx