One of the tricks I like to use is creation of a log file while my addin runs. I typically will log any errors the addin hits. In the case of the Copy to Mobile addin, I decided to add some logging to the file and keep track of the pageIDs which have been copied.
Dan gave me the original codebase for this. If you've looked through the code, there is a method called showErrorBox(string) which Dan was using to pop up dialogs with errors as they occurred. Obviously, I made a change to get rid of the message box and call my logging method (LogComment(string)) instead. Two different ways of achieving the same goal - neither is better or worse, they are just different. While we are very reluctant to introduce code changes without a reason - and this counts - since I'm acting as all three roles for this addin, I went ahead and made the change. The primary benefits I was shooting for were resiliency and avoiding alerting the user with error dialogs which point out problems which cannot be fixed. For instance, if the addin fails to delete a page it thinks is a duplicate, and the copy to mobile call still works, the user gets two copies of a page instead of one. Worst case, he can delete the duplicated page from his mobile device or OneNote when he notices this, but he doesn't have to deal with a dialog in the middle of his workflow. He just presses the button and goes.
Additionally, the dialog presented in the "failure to delete duplicate page" did not tell him which specific page was duplicated. He would have to go hunting for it in the mobile device notebook. Again, this interrupts his workflow to track down an error. I decided to just leave him alone and that more, but duplicate, data was better than no data.
Lastly, since I want to fix any bugs in this addin, I wanted to log the specific error the app hit. Thrown exceptions converted to strings are never going to make sense to the user, so I just log them so the user doesn't have to write anything down when reporting problems. The log may not have enough information for me, but it serves as a starting point. I could have alerted the user to the failure and logged the specifics in the background, but I really wanted to avoid modal error dialogs if at all possible.
So for this particular addin, the log file pulls double duty. It keeps track of the copied pages and keeps a record of errors the addin hits. That makes it a little easier for me to troubleshoot two different types of problems, and making my life easy is a good thing.