Question about Exception Handling.

Question

Hello Everyone,

I have a question about Exception Handling.

I was just reading the Exception Handling article on MSDN and it says "Do not handle errors by catching non-specific exceptions, such as System.Exception, System.SystemException, and so on, in framework code."

So, lets says im doing a bunch of database transactions, I would catch all of these? SQLException, ArgumentNullException, InvalidCastException.   I would hope that they don't fire but just want to be prepared.

Why is using System.Exception not a good practice?

I could then in my code Catch SQLException, and Catch System.Exception to catch all others.. Is this not common practice. If not please explain why.

I want to do this correct, so any advice or suggestions would be greatly appreciated.

Thanks

Answer 1

Can you show the article, by instance the SQLException catches only errors in SQL Transact while in my idea the Exception catches everything which is not yet catched.

Probably that is something I've also thought (and maybe even written) once. But in my idea learned practise me that it makes it much to less maintainable.

But I am curious to see the article.

---

Success
Cor

Answer 2

Your exception handlers should move from specific to general. First have a SqlException handler block, then gradually move towards the catch-all System.Exception block. This way you could introduced custom exception handling as well as make sure there are no exceptions which remain unhandled

---

Ganesh Ranganathan
[Please mark the post as answer if it answers your question]
blog.ganeshzone.net

Answer 3

Your exception handlers should move from specific to general. First have a SqlException handler block, then gradually move towards the catch-all System.Exception block. This way you could introduced custom exception handling as well as make sure there are no exceptions which remain unhandled

---

Ganesh Ranganathan
[Please mark the post as answer if it answers your question]
blog.ganeshzone.net

Answer 4

Thanks everyone for the replies.

@Cor:  The article I was referring to can be found here. http://msdn.microsoft.com/en-us/library/ms229005.aspx

@Arjun:  Thank you for taking time to explain this.  
           
In my application I am not rethrowing any of the errors, I log them to a database, then determine the state of the application and continue on.
That way the user does not get an ugly messages.


Again, Thanks all of you for your help.. I appreciate it.

Answer 5

Hi,

In my idea is the sentence on that page confusing. Something like: You should not go to the moon if you don't have a plane which goes to the moon.

I've thought a little bit about the answer from Ganesh which is proposed by Bill Vaughn.

In version 2003 I made often code like this for AdoNet

Try
AdoNetCode
Catch exs as SQLException
..Handle SQLException
Catch ex as Exception
...Hanlde
End Catch

But the SQLEception was only doing something for me at debug time (and that bad I am not in SQL transact. Code which is difficult, I've mostly checked more times using the profiler and SQL analyzer before it even reaches my VB code; For instance the catch of a concurrency error is not done by it because that is AdoNet.

I think I should try that SQLException once in the Test part which are in Visual Studio 2008 and even better in Visual Studio 2010.

Reading this thread I think that it is a bad article, it forces you in a way to check for a nullexcetiong in a try catch, while there is a perfect way to test it.

In general you should avoid a Try Catch if there is a better way to validate in advance; which cannot be done if the data can be affected from outside your program, by instance a disk, a port or a database.

---

Success
Cor

Answer 6

You should not go to the moon if you don't have a plane which goes to the moon.

Thank you Cor!  ;)

I will continue researching the subject, but I think I can move forward now.

Again, Thanks to everyone for all your help. I appreciate it.