Just a couple of points on exceptions in general...
Be aware that catching all Exceptions with code like
catch(Exception ex)
(well CLS compliant ones anyway) is potentially a bad thing - you are basically saying that whatever goes wrong you are happy to catch and correctly handle the resultant exception, regardless of what it is. Some exceptions are going to be well beyond your ability to deal with e.g. OutOfMemoryException, StackOverflowException and similar, if you must catch all exceptions then you also probably want to rethrow them rather than just swallowing them...
Also using a series of specific catch blocks, that target the exceptions you are expecting to deal with, rather than a single catch block with a nested if statement makes it much harder for exceptions to be accidently ignored during development only to surface in someway after deployment.
As a final note you also need to be aware of the relative performance aspects, although exceptions can be less efficient than checking in advance you need to weigh up a couple of things:
1) How often is the exception likely to occur? If you are checking for the presence of a file before opening it and you would expect the file to be present nearly all the time it may be simpler in the long run to assume it is present and handle the odd occasion when it isn't by catching the exception.
2) Code like
//May not compile, no VS on this pc but you should get the idea
if (System.IO.File.Exists("c:\\test.txt")
{
System.IO.FileStream = System.IO.File.Open("C:\\test.txt");
//use fs
}
introduces a race condition - there is always the possibility that the file could be present when the initial check is performed but deleted before the attempt to open it! You would still need to handle the possibility of an exception anyway...