Catching exceptions

[Andy B.]

What order should you catch exceptions in? What is a good rule to use? I
have things like TransactionAbortedException, TransactionInDoubtException
SqlException and Exception. What order should they be done in?

 

[Mike Lovell]

What order should you catch exceptions in? What is a good rule to use? I

have things like TransactionAbortedException, TransactionInDoubtException
SqlException and Exception. What order should they be done in?

Well only a single exception type is going to be thrown, I guess the answer
would be most specific to less specific. So end on the actual 'Exception'
class. If it's derived from another class you're eventually going to get a
hit as you go down the chain.

This is something I actually recently covered, catching multiple Exceptions
in a single 'catch' block:

http://www.gotinker.com/2010/03/09/catching-multiple-exceptions-in-a-single-block/

Which can come in handy if you want to implement the same behavior for
different types of Exceptions. Usually you should be concentrating on some
quite specific errors that could happen in your code for your handling. If
you are NOT expecting the error, then you're in unknown territory and you
really should throw and abort (and preferable log)

 

[Mr. Arnold]

What order should you catch exceptions in? What is a good rule to use? I
have things like TransactionAbortedException, TransactionInDoubtException
SqlException and Exception. What order should they be done in?

<http://www.zdnetasia.com/insight/software/0,39044822,39045022,00.htm>

2. Order catch blocks from specific to general
When placing catch blocks in your code that are set to catch different
types of exception, always place them in order from most specific to
most general. Doing so not only makes it clear that specific exception
types will be handled before the more general types, but it also helps
other developers reading your code understand what's going on.

 

[Andy B.]

Well only a single exception type is going to be thrown, I guess the
answer would be most specific to less specific. So end on the actual
'Exception' class. If it's derived from another class you're eventually
going to get a hit as you go down the chain.

This is something I actually recently covered, catching multiple
Exceptions in a single 'catch' block:

http://www.gotinker.com/2010/03/09/catching-multiple-exceptions-in-a-single-block/

Which can come in handy if you want to implement the same behavior for
different types of Exceptions. Usually you should be concentrating on
some quite specific errors that could happen in your code for your
handling. If you are NOT expecting the error, then you're in unknown
territory and you really should throw and abort (and preferable log)

In the block of code I am working on now, I am writing a CLR stored
procedure that inserts a row into a table. I know the most common exception
that will be thrown is a unique constraint violation on a particular column.
I could use the TransactionAbortedException to deal with this problem
because it catches any error that would make the transaction fail. I just
have 1 problem with it: How exactly do you tell for sure what the exception
really is? There isn't any error code or status code anywhere in the
TransactionAbortedException class to test for. So, how will my code really
truely know what the problem is?