I wouldn't take that sample code seriously, I guess it's old. As the others said, in that case a cast as or try would be more appropriate. The Framework Design Guidelines <http://msdn.microsoft.com/en-us/library/ms229042.aspx> (BOOK <http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/ 0321246756> ) covers all of these sorts of issues nicely, especially about what is "exceptional" or not, and that sample is not exceptional.
A ramble for newer coders here ... I fell for the trap in the my earlier .NET coding years of over-catching. I think a lot of people had to get out of the habit of swallowing exceptions. I've recently been working on app code I wrote over the last several years, and I have been slowly removing hundreds and hundreds of lines of try-catch blocks. I can see now that most of them do nothing but clutter up the code. In my old UI code I keep finding stuff like this skeleton: try { dataSource = DataLayer.GetSomething(); } Catch (Exception ex) { MessageBox.Show("Something rotten happened. " + ex.ToString()); } It's completely useless, as the method call is not supposed to fail, and if it does fail then something is so very stuffed up that the app should crash and stop anyway. I remove all the obviously useless try-catch blocks as I go. You should never try-catch unless you know specifically what you're going to catch and you know what to do with it. Greg Ps. Thanks for the replies about source control of DB scripts. We'll be discussing this over the coming days.