As a follow up to my transitive exception post a little over a week ago, I hacked together a tool that almost does what I want.

See this page for some sample output, the results of running against the Whidbey Beta 1 release of mscorlib.dll (available as a free download off of MSDN). Notice that you get a full stack trace in cases where the method in question doesn't directly throw something, but rather a piece of called code does. It seems to be pretty accurate, and is actually giving me a warm and fuzzy feeling about the state of managed code and exceptions. It doesn't look like we let a lot of crap leak out of methods at all. Having a Java-heavy background, not having checked exceptions is seemingly giving me bouts of paranoia. :)

Here's a quick list of noted exclusions the tool doesn't currently handle at all:

• Late bound method calls. Virtuals, delegates, reflection, and the like.
• Well known system exceptions coming from infrastructure or unmanaged interop.

I have plans for both, but haven't had a chance to get something workable just yet.

You'll also notice that exception constructor arguments are actually captured and output, but only when literals are used at the call site. This is very seldom the case as a result of a little thing we like to call resources that are - thankfully - used pretty ubiquitously throughout the Framework. I'm planning on doing some reflection at the time of analysis to try and tease out the right resource string. I think it's pretty neat to see this data in the report.

I would publish the code for the tool, but unfortunately I've taken a dependency on some "secret-squirrel" (Hi Mark) static analysis technology that can't leave MS's comfy confines.

Diclaimer: This information is for research only, and should not be considered official Microsoft documentation of any sort. Please refer to the .NET Framework SDK for details on exceptions that a given method might throw.