Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

The ArcGIS 10 add-in I'm working on is pretty simple -- just a tool control and a dockable window. I'm handling the specific exceptions I anticipate occuring at the source and throwing everything else, but what is the best practice for handling those unexpected exceptions in the add-in framework?

I'm currently just doing a catch (System.Exception ex) and showing it in a MessageBox in every method that doesn't have a higher-level method I could handle it in, but this doesn't seem like the best practice (and of course, FxCop is whining about it).

Is there any facility in the ArcGIS 10 add-in framework for a top-level exception handler to be hooked up, for example to the Application.ThreadException or AppDomain.UnhandledException events?

Seeing as add-ins are just class libraries and not applications with no access to the underlying application's startup code (from what I gather, those events have to be hooked up very early in the startup process), my guess is no, but I thought I'd ask if any experts out there had any suggestions on how "unexpected" exceptions should be handled in add-ins.

share|improve this question
1  
Just FYI: here is a link trying to get this fixed a little bit at esri –  baens Aug 29 '11 at 21:24
    
@blah238 What have you done to solve your problem? Can you please give me some pointers to handle unhandled exceptions? –  Emi Jan 14 '13 at 9:27
    
Put an exception handler at every entry point to your code. –  blah238 Jan 14 '13 at 9:28
    
At every entry point?!! There is no other way to handle it from top level? –  Emi Jan 15 '13 at 4:48
    
That is my understanding, yes. See @baens link above if you'd like to see this improved. –  blah238 Jan 15 '13 at 7:28

2 Answers 2

up vote 7 down vote accepted

As far as I can tell you are implementing the error handling that ESRI is currently putting out there as best practice. If you were to grab a hold of the application's (ArcMap) unhandled exceptions you could potentially be then displaying messages about errors that were not part of your AddIn. Most of the AddIns you write are probably going to be buttons and those really only have two major routes that unexpected errors would be caught and displayed (onClick and onUpdate).

Just remember to use the 'throw' instead of 'throw ex'. There is a minute difference, but it results in retaining the error's lineage as it bubbles up from called functions.

share|improve this answer
    
Thanks, this is what I expected to be the case as all the ESRI samples do it the same way. –  blah238 Jul 28 '11 at 17:19
    
@Troy Schmidt can you please give me a pointer about when I am using a dockable window, how can I handle unhandled exceptions? And from where and what should I "Throw"? –  Emi Jan 14 '13 at 7:01

I am working with an ArcGIS add-in. My add-in consists a dockable window and a tool control. I am trying to keep log of ArcGIS crash because of my tool. And I get some success on top-level exception handling using Application.ThreadException. As thread exception works only for UI thread, after instantiating dockable window, any exception that can be a cause to crash ArcGIS, it catches that, but it does not work before instantiating dockable window.

    public class AddinImpl : ESRI.ArcGIS.Desktop.AddIns.DockableWindow
    {
        private WatershedDelineationDockableWindow m_windowUI;

        public WatershedDelineationDockableWindow GetUI
        {
            get
            {
                return m_windowUI;
            }
        }

        public AddinImpl()
        {
            Application.ThreadException += MYThreadHandler;
            Log.Info("Creating dockable window.");
        }

        static void MYThreadHandler(object sender, ThreadExceptionEventArgs e)
        {
            Log.Error("unhandled error in thread " + e.Exception.ToString());
            MessageBox.Show("unhandled error in thread " + e.Exception.ToString());
        }

        protected override IntPtr OnCreateChild()
        {
            m_windowUI = new WatershedDelineationDockableWindow(this.Hook);
            return m_windowUI.Handle;
        }

        protected override void Dispose(bool disposing)
        {
            if (m_windowUI != null)
                m_windowUI.Dispose(disposing);

            base.Dispose(disposing);
            Log.Info("Closing dockable window ");
        }
    }

This does top-level exception handling after instantiating UI

share|improve this answer
    
Interesting, thanks for posting your findings. I'll have to play around with this. In particular, I wonder if the dockable window is really necessary or if it could be set up in an extension. –  blah238 Jan 17 '13 at 6:27
    
@blah238 Thread.Exception also works when I put it on button's onclick method. I think it works for any control that interacts with UI. –  Emi Jan 17 '13 at 6:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.