And just my 2 cents to add to Charles... programming with try catch as FUNCTIONALITY is bad practice. In other words, I'll use an example: In the .NET 1.x world lets say you wanted to convert some string data to a numeric but you had no way of knowing if the data coming in is actually representable by a number. You could use the Convert.ToInt32(someString) (returns 0 if it can, might throw an exception though if the string is way out of whack) or maybe you could have written something like try { someNum = Int32.Parse(someStringRepresentation); } catch (System.Exception ex) { // logic here } (and as somebody mentioned you'd actually not use the general System.Exception class, but something more specific). While this is "ok", if you try to run this same operation on thousands of strings and a good portion of them are failing, you'll see this has a huge performance hit. So as Charles mentioned, you'd want to do something to check and make sure it'd work. .NET 2.0 added a TryParse method which basically uses Regex or some other method to check before attempting to parse, increasing the speed and performance drastically.
Try/Catch should only be used to catch REAL exceptions. In other words, something could possibly happen here out of the norm such as an invalid IO operation (network drive lost, maybe?)... not that my bad coding is going to produce errors. Embedding an entire huge piece of functionality in a try/catch is lazy and irresponsible of a programmer -- you should seek out, as Charles suggested, the root of the problem and prevent those errors from being there in the first place.