always try-catch external resource calls?

Catch only exceptions that you can handle. So for example when using external resources, the best practice is to catch specific exceptions that you know you can handle. In case of files this can be (IOException, SecurityException, etc), in case of Database the exception can be SqlException or others.

In any case, don't catch exceptions that you don't handle, let them flow to a upper layer that can. Or if for some reason you do catch exceptions but don't handle them, rethrow them using just throw; (which will create an rethrow IL op, as opposed to trow).

In case of using resources that you don't know what type of exceptions might throw, you are kind of forced to catch the general exception type. And in this case the safes thing would be to use the said resources from a different app domain (if possible), or let the exception bubble up to top level (ex UI) where they can be displayed or logged.

I think there are three reasons to have a catch block:

• You can handle the exception and recover (from "low level" code)
• You want to rewrap the exception (again, from "low level" code)
• You're at the top of the stack, and while you can't recover the operation itself, you don't want the whole app to go down

If you stick to these, you should have very few catch blocks compared with try/finally blocks - and those try/finally blocks are almost always just calling Dispose, and therefore best written as using statements.

Bottom line: It's very important to have a finally block to free resources, but catch blocks should usually be rarer.

> Know when to set up a try/catch block. For example, you can programmatically check for a condition that is likely to occur without using exception handling. In other situations, using exception handling to catch an error condition is appropriate.

That's what I found and it makes sense to me.. Check manually for the obvious things, let try-catch do the rest..