I recall reading that chapter in the past and subsequently becoming wary of using exceptions excessively. It's hard to disagree with what it says with regards to performance but with respect to programming flexibility and elegance exceptions are, to my mind
at least, a superior approach to putting information into method return values.
The article states that exceptional paths should only be taken less than one time in a thousand. But at the same time a lot of the .Net base libraries throw exceptions at the drop of a hat.
A classic example is System.IO.File, whenever an attempt is made to open a file exceptions will be thrown if the file doesn't exist, the user doesn't have permission, the file is already locked etc. To me this makes perfect sense. If the Open method just returned
false my application would then have to look somewhere else to find out why the file could not be opened.
My, rather long winded, point is that exceptions maybe aren't good in situations needing optimal performance, such as ASP.Net, but they are a pretty good way to handle and promulgate error information otherwise!
I am starting to think that I should use exceptions more in client side code rather than less. If a method has three input parameters needing validation wouldn't it be better to throw an exception to inidcate how the parameters are incorrect rather then just
returning false or something?