Word VSTO swallows exceptions at runtime without debugging?

Question

Place this code somewhere in a Word document level VSTO solution outside of ThisDocument_Startup (create a ribbon button, with a click event):

int zero = 0;
int divideByZero = 10 / zero;

Start without debugging (Ctrl + F5), Result: Exception is swallowed, the rest of the code fails silently.

The exception will be visible if placed in ThisDocument_Startup, but it appears nowhere else. Microsoft's VSTO forums and the MSDN documentation seem to feel Try...Catch should be used - which is not a big deal for known unknowns. What about the unknown unknowns?

All the common ways of dealing with unhandled exceptions for managed code don't seem to work, presumably because of VSTO using managed code with Office COM Interops:

//These don't work
AppDomain.CurrentDomain.UnhandledException ...
System.Windows.Forms.Application.ThreadException ...

I've read posts about troubleshooting VSTO code that always seems to lead to placing Try...Catch around practically everything!

Is there any better way to handle known and unknown (now invisible and silent!) failures?

Answer 1

Office tends to eat every exception. I would always log everything to a file. Don't expect any help from MS.

Answer 2

i can get a ********** Exception Text ********** System.DivideByZeroException: Attempted to divide by zero.

with app level addin project.

Are you only seeing this with Doc level customisation projects? Also only in word or is this also happening in Excel?

Answer 3

I think the problem is isolated only to exceptions around the "add-in user interface" - which happens to be a direct setting found here (Word 2007):

Word Options > Advanced > General > "Show add-in user interface errors"

Answer 4

I had the same issue with an application-level add-in in Word.

If you are running your add-in by launching it from Visual Studio with F5, then you'll always get "unhandled by user code" in VS (eg 2008 SP1), unless:

• you uncheck the Visual Studio setting "Break when an exception is .. user-unhandled" for CLR exceptions, or

• you liberally apply the [System.Diagnostics.DebuggerNonUserCodeAttribute()] annotation.

Once you've done one of these, UnhandledException/ThreadException seem to work.