Capturing specific exceptions (from third parties) without doing string matching

Question

I have repeatedly found myself in situations where I want to catch an exception (in .net), but there may be multiple exceptions with different messages that I want to handle differently.

When I view the exception in a debugger, I usually cannot find any piece of metadata that shows me a unique number representing that particular exception, so I end up writing string comparisons. The exception class is the same.

This is tedious and just seems wrong. Am I missing some good way to uniquely identify exceptions without doing a string comparison? Or do I just happen to work with some bad libraries that don't throw exceptions with good metadata? (Examples so far included ADODB, and OpenNETCF).

pseudocode explaining what i'm describing:

Try
...
Catch myexception as System.Runtime.InteropServices.COMException
   switch(myexception.message){
      case "oneexceptionmessage":
         handleOneException()
      case "twoexceptionmessage":
         handleTwoException()
   }
End Try

End Try

• Exception types are different
• Inner exceptions are null
• HResults may be different, but aren't normally accessible as protected properties

Answer 1

Instead of using the message of the exception class, the OOP way of doing things would suggest that you create a subclass to represent each of your exceptional circumstances. This way would be, most importantly, strongly typed and there would be no string comparison.

Answer 2

Put multiple catch statements in order from most specific to least specific

Try

Catch dboe as DivideByZeroException

Catch oome as OutOfMemoryException

Catch ...

Catch e as Exception

End Try

Answer 3

You may wish to follow Scott's suggestion and create your own set of Exception classes (based on your observation of what the libraries throw) anyway, especially if we're talking about a large app (or set of them) that all use those libraries.

I'm suggesting a sort of exception-factory class, that encapsulates all the "tedious / wrong" string comparison and generates appropriate exceptions of your own for the calling code to handle or re-throw. This would require the exception handlers in your calling code to pass exceptions they catch to the factory in order to obtain a more-useful result. Might be overkill, but at least you only write the string comparisons once, in one place...

Answer 4

Though I haven't seen it in the debugger, I looked up the documentation for the handheld library we use and saw HResult property. I now see that I can reference this for the database comexceptions too.

I had not noticed it before because I was simply browsing through values in the debugger, and it wasn't there.

Maybe these are always unique?

This is how the documentation describes this property being used - thought I'm not clear if it's enforced that any Subclass of Exception would always enforce this.