Exception Helper for VS 2005

today I updated the open source Exception Helper plugin for Visual Studio 2005.  You can view a short screen cast demonstrating it’s installation and usage (about 4 minutes)

You can download from workspaces.gotdotnet.com/project42

7 Comments so far

  1.   David Gardiner on July 18th, 2006          

    i had the Refactor for VB 2005 installed, but that only comes with DXcore 1.2

    I needed to install the latest version 2.01 to get your extension working.


  2.   Michael Kennedy on July 18th, 2006          

    Very nice, thanks!

    Any chance of using reflection to determine all exceptions, even the undocumented ones? With the new .NET 2.0 reflection API, it’s probably possible, but I don’t know how hard.


  3.   Alex Hoffman on July 18th, 2006          

    What a great utility! Many thanks.

  4.   bill on July 18th, 2006          

    Hi Dave,

    Yes, it’s only designed for DXCore 2.0. that’s a major version upgrade, so I went with supporting jsut the one flavour. It was originally written against 1.2, so should probably work there, except you’d have ot manually install.
    The new version of Refactor for VB (that uses DXCore) should be available very soon 🙂 The Pro version has already been released.

  5.   bill on July 18th, 2006          

    Thanks Alex 🙂

  6.   bill on July 18th, 2006          

    Hi Michael,

    the concept of using static code analysis was considered. It does however get very complex as you need to walk down every method call, determine what exceptions can be raised, what are handled, and whether or not any handling is conditional. It’s a lot of work, and would most likely end in false positives. (at least that’d be better than omitting exceptions )

    But even if we did that, and we then got a list of exceptions, you really have to ask what value is that to the user if there is no documentation as to why those exceptions might be raised.

    For example, let’s say you call method
    Which we determine somehwere in the code graph throws an ArguementNullException. how much use to you is that, unless we tell you whether it’s a, b, c and/or d that applies to ? and what if the ArguementNullException is thrown by a method that Foo calls, and is not directly linked to a, b, c or d.

    So at the end of the day, I think what you really need is the documentation. so that’s why we went the easy route of using the XML documentation, as it is also really the best route 😉

  7.   Michael Kennedy on July 24th, 2006          


    I suppose that it is slightly more complicated than just detecting the throwing of certain exception types – they could be caught and re-thrown as inner exceptions as you suggested.

    I see the documentation choice for Framework code with good docs – that’s much better than what we’ve got so far.

    Thanks again,