AFAIK, add-ins can’t use “global” exception handlers using AppDomain.UnhandledException, I think that because maybe all add-ins are loaded in the same AppDomain (not sure) and therefore it wouldn’t be suitable that an add-in handles the unhandled exception of another add-in… Anyway, I use exception handlers all around the code of my MZ-Tools add-in. Although I use a single method to treat the exceptions (showing an error to the user with a “Send Report” button, etc.), I made two errors that I am now (costly) fixing for next versions:

– The bug report misses important information about the IDE where the add-in causes the problem, including the IDE version. While in MZ-Tools 6.0 I use a different add-in assembly for each target IDE (so I can actually know the version), future versions of MZ-Tools will use a single add-in dll to target multiple IDEs.

– That method didn’t receive the DTE object and when I modified it to receive it, I realized that a lot of methods that were trapping exceptions didn’t have that DTE object to pass, because they were “helper” static (shared in C#) methods, so I had to do a lot of refactoring for every method to get access to the DTE object that the Connect class owns.

I have summarized what I consider good practices in this new article:

HOWTO: Handle exceptions in a Visual Studio add-in.
http://www.mztools.com/articles/2010/MZ2010002.aspx