My question is really the same as this one "Finding out what exceptions a method might throw in C#". However, I would really like to know if anyone knows of a way to determine the stack of all the exceptions that may be thrown by a given method. I am hoping for a tool or utility that I can analyze code at compile time or through reflection like FxCop, StyleCop, or NCover. I do not need this information at run time I just want to make sure we are trapping exceptions and logging them correctly in out code.
We are currently trapping the exceptions that we know about and logging all the wild cards. This does work well; however, i was just hoping someone has used or knows of a tool that can discover this information.
My methodology for this type of situation is to handle all the exceptions that I want to and then override the UnhandledException event of the application to log any other's that I don't know about. Then if I come up against any that I think I could possibly resolve then I would just update accordingly.
Hope that helps!
Following up to my previous answer, I've managed to create a basic exception finder. It utilises a reflection-based
ILReader
class, available here on Haibo Luo's MSDN blog. (Just add a reference to the project.)Updates:
Here is the code, in full. You simply want to use the
GetAllExceptions(MethodBase)
method either as an extension or static method.To summarise, this algorithm recursively enumerates (depth-first) any methods called within the specified one, by reading the CIL instructions (as well as keeping track of methods already visited). It maintains a single list of collections that can be thrown using a
HashSet<T>
object, which is returned at the end. It additionally maintains an array of local variables and a stack, in order to keep track of exceptions that aren't thrown immediately after they are created.Of course, this code isn't infallible in it's current state. There are a few improvements that I need to make for it to be robust, namely:
Detect exceptions that aren't thrown directly using an exception constructor. (i.e. The exception is retrieved from a local variable or a method call.)Support exceptions popped off the stack then later pushed back on.rethrow
instruction is detected.Apart from that, I believe the code is reasonably complete. It may take a bit more investigation before I figure out exactly how to do the flow-control detection (though I believe I can see how it operates at the IL-level now).
These functions could probably be turned into an entire library if one was to create a full-featured "exception analyser", but hopefully this will at least provide a sound starting point for such a tool, if not already good enough in its current state.
Anyway, hope that helps!
Unlike java C# does not have the concept of checked exceptions.
On a macro level you should catch everything and log or inform the user of the error. When you know about the specific exceptions a method may raise then definetly handle that appropriately but be sure to let any other exceptions bubble up (preferably) or log them, otherwise you will have bugs that you will not be able to find and generally make life miserable for anyone hired to help reduce the bug list - have been there, not fun! :)