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.
