What types of code blocks should I enclose with try-catch statement? [closed]

Question

I have read and discussed the following questions and articles deeply and many others now and in the past:

When to use try/catch blocks?

Main method code entirely inside try/catch: Is it bad practice?

When to use Try Catch blocks

I will make this article the coding standard of exception handling in my organization! avery nice one but didn't answer me: http://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

What is the Best practice for try catch blocks to create clean code?

Best practices for exception management in Java or C# Here: I didn't like this statment :( You should not try to catch each and every exception in every possible place.

Should multiple Try/Catch blocks in a method be combined

I have a problem when i need to decide to enclose some block of code with try-catch statement, I know that the code should be enclosed is the faulty code, And i must check what I can check, but for example: I need to write a line in some text file, I should check if the file is exists, and if I have permission to write on it, should I check if there is a space on the disk, or the disk is writable, and if i checked the space, what if something happened while I writing the file (Some other app or thread used the space, or the removable drive has been removed?), Is it a best practice if I checked those things and handled IOException and SecurityException and other potential exceptions, or I should only check without try-catch?

Another example: I am using EntityFramework to access database, when accessing something may contact the database, I know I should check the connection if closed and try to open it, but there are many and many things may cause a failure in this statement, the database may be on a removable drive, this drive may be removed while reading, the service of the DBMS may stop for any reason, no space exception may be thrown, the scheme of the database may change after I try to execute my code for some **** reason,How can I prevent my code from fail, can I just check every thing I can check, and go on? or I should use try catch for exception I can expect even though I have checked them?

Give me references of your answers please, not a general answers!

EDIT

And sure read this : http://msdn.microsoft.com/en-us/library/seyhszts.aspx

Answer 1

Good question! One of your links (Daniel Turini) is one of my favourites. I go back to it again and again when my thinking needs some straightening out.

A good way of expressing my attitude to exception-handling is: only handle exceptions that you can handle. Meaning that you can never work out what to do in response to any possible exception that comes up, and implement this in your code. There are some "expected" exceptions that can be dealt with - but what the code does in response to these is a design decision in itself. IMHO the priority in handling these is not to leave a mess behind after the app shuts down (or at least, backs out of the particular transaction it was involved in) - not for the application to be able to carry on regardless, because shutting down with a graceful "I don't know why, but this exception happened" notification (to a log/IT email/MsgBox, whatever) is somehow a "bad thing".

The direct opposite of this kind of design is the kind of exception-handling that tries to makes the app a kind of "nuclear-Armageddon-survivor". Tries to... I've seen code that responds to IO errors by assuming the network file-server is down, and branches to trying to work, in some undesigned way, on the C: drive. And code that attempts to SELECT FROM ATable: if the table doesn't exist, it CREATES it!!! Every time someone writes code like this, a baby possum dies.

Turini says "never swallow exceptions". What I'm thinking is an extension of this: IMHO you have to be very careful about letting an app carry on, even in response to a known, definite type of exception, with a known cause: because even this constitutes "swallowing" exceptions. Do it, but do it carefully and well.

So in my way of thinking there's always room for a generic "any other case" exception-handler, that delegates the decision up to a higher power (a human being) by logging the details of what happened and just shutting down the app.

My 2c..