2

I'm developing a suite of Excel add-ins for a company. I haven't done add-ins before, so I'm not terribly familiar with some of the intricacies. After delivering my first product, the user encountered errors that I didn't experience/encounter/notice during my testing. Additionally, I was having difficulty reproducing them from within Visual Studios debug environment.

I wound up writing a light weight logging class that received messages from various parts of the program. The program isn't huge, so it wasn't a whole lot of work. But what I did end up with was nearly every single line of code wrapped up in Try... Catch blocks so I could log things happening in the users environment.

I think I implemented it decently enough, I tried to avoid wrapping calls to other classes or modules and instead putting the block inside the call, so I could more accurately identify who was throwing, and I didn't swallow anything, I always threw the exception after I recorded the information I was interested in.

My question is, essentially, is this okay? Is there a better way to tackle this? Am I waaaay off base?

Quick Edit: Importantly, it did work. And I was able to nail down the bug and resolve it.

Michael
  • 1,803
  • 1
  • 17
  • 26
  • Related: http://stackoverflow.com/questions/2524381/c-sharp-winforms-exception-handling-for-events – Kirk Woll Feb 07 '13 at 23:37
  • 3
    You could opt to just log the exceptions - the stack trace should give you all the same info that you are getting now at a much lower cost of entry and maintenance and readability. – Sam Axe Feb 07 '13 at 23:38
  • You may want to utilize `Trace Listeners`. Encompassing your entire project in a `Try` and `Catch` can be fairly dangerous. Plus, `Try` and `Catch` usually have far greater overhead. – Greg Feb 07 '13 at 23:47
  • Does [IntelliTrace](http://blogs.msdn.com/b/visualstudioalm/archive/2012/03/16/running-intellitrace-on-applications-in-production.aspx) work with Excel add-ins? – DaveShaw Feb 07 '13 at 23:50
  • Thank you all for the suggestions. I'm gonna have a look into optimizing a bit, and investigate some alternative production debugging methods. – Michael Feb 08 '13 at 00:12

1 Answers1

0

No, you are not way off base. I believe this is the only way to handle errors when writing Add-ins. I am selling an Outlook add-in myself which uses this pattern. A couple of notes though:

  1. You only need to wrap the top-level methods, either exposed to the user interface directly or triggered by other events.

  2. Make sure your logging routine traverses the Exception tree recursively, also logging InnerExceptions.

  3. Instead of rethrowing the exception you might consider displaying some sort of error form instead.

And then a couple of comments to those notes:

  1. I'm sure you understand this, but your comment "nearly every single line of code is wrapped(...)" made me want to underline this. But yes, all your code should eventually end up in a catch (System.Exception)-block so that you can log your Exception. I disagree completely with Greg saying this is "dangerous". What is dangerous is not handling your exceptions.

  2. If you do this I don't think you need to "avoid wrapping calls to other classes and modules", if I understand you correctly. I have a published a convenient extension method GetAsString that allows me to log what I need at github.

  3. In Outlook, if an Exception bubbles up to Outlook itself, your Add-in might get disabled or even crash Outlook if it happens on a background thread. Isn't it the same in Excel? Therefore I go to great lengths not to let any exception out of my application. Of course you need to make sure your application can continue running after this, or allow for a graceful shutdown.

Nilzor
  • 18,082
  • 22
  • 100
  • 167