When catching an exception in .NET, you can have as many type-specific exception blocks as needed. But I usually try to have at least one "general" exception catch block. But is there a way to get the type of the "real" exception thrown that is caught by the generic exception handler, perhaps using reflection?
For example, if I have
Catch ex As System.ServiceModel.FaultException(Of InvalidUser)
ProcessModuleLoadException(Me, ex)
Catch ex As System.ServiceModel.FaultException(Of SQLExceptions)
ProcessModuleLoadException(Me, ex)
Catch ex As System.ServiceModel.FaultException(Of DataNullReference)
ProcessModuleLoadException(Me, ex)
Catch ex As System.ServiceModel.FaultException
ProcessModuleLoadException(Me, ex)
Catch ex As Exception
ProcessModuleLoadException(Me, ex)
(I have broken them out for debugging, even though I do the same thing with each exception).
In short, in "Catch ex As System.ServiceModel.FaultException" I want to examine "ex" and get the base "real" type of the exception, either as a type (mostly for debugging so I can add another catch block) or as a string (for logging).
But, inside the Catch block, "ex" has already been cast to it's parent class, so any original properties and information about the original exception seem to be lost.
Suggestions?
Even though the
Exception
has been cast to its parent class, you can still callGetType
to obtain its underlying concrete type (pardon my C#):If this is just for diagnostic purposes, you can log
ex.ToString()
, which includes the underlying type by default (in addition to the stack trace, etc.) like this:.GetType
will still return its actual type.What about catching it as a generic system exception then using the "is" lingo to test the actual type?
This only a slight modification from Jeff's answer:
I was looking for something like what Chris is describing, and specifically I wanted to handle the original exception after it had been thrown again by a few generic exceptions, and have only one handler that I could call for all entry points. And since re-throwing an exception will wrap it with its own exception type, we need to add loop to go through the inner exceptions, and check the first exception thrown.
So here's the code I ended up with:
The advantage of this is that you could have an extensive range of exception types you handle throughout the program, with lots of handling code, but you could handle them all in one place.
I know this reply is a little late for this question, but I thought I would share, if perhaps to help anyone looking for the same thing I was looking for.