Complément ArcGIS 10: gestion des exceptions de niveau supérieur

Le complément ArcGIS 10 sur lequel je travaille est assez simple - juste un contrôle d'outil et une fenêtre ancrable. Je gère les exceptions spécifiques que je prévois de se produire à la source et de jeter tout le reste, mais quelle est la meilleure pratique pour gérer ces exceptions inattendues dans le cadre du complément?

Je suis en train de faire un catch (System.Exception ex)et de le montrer dans une MessageBox dans chaque méthode qui n'a pas de méthode de niveau supérieur dans laquelle je pourrais le gérer, mais cela ne semble pas être la meilleure pratique (et bien sûr, FxCop se plaint à propos de ça).

Existe-t-il une fonctionnalité dans la structure de complément ArcGIS 10 pour un gestionnaire d'exceptions de niveau supérieur à connecter, par exemple aux événements Application.ThreadExceptionou AppDomain.UnhandledException?

Étant donné que les compléments ne sont que des bibliothèques de classes et non des applications sans accès au code de démarrage de l'application sous-jacente (d'après ce que je comprends, ces événements doivent être connectés très tôt dans le processus de démarrage), je suppose que non, mais je pensais Je voudrais savoir si des experts ont des suggestions sur la manière de gérer les exceptions "inattendues" dans les compléments.

Autant que je sache, vous implémentez la gestion des erreurs que ESRI propose actuellement comme meilleure pratique. Si vous deviez saisir les exceptions non gérées de l'application ( ArcMap ), vous pourriez éventuellement afficher des messages sur des erreurs qui ne faisaient pas partie de votre complément. La plupart des compléments que vous écrivez seront probablement des boutons et ceux-ci n'ont vraiment que deux routes principales pour que des erreurs inattendues soient détectées et affichées ( onClick et onUpdate ).

N'oubliez pas d'utiliser le ' throw ' au lieu de ' throw ex '. Il y a une petite différence, mais cela se traduit par la conservation de la lignée de l'erreur car elle bouillonne à partir des fonctions appelées.

Je travaille avec un complément ArcGIS. Mon complément se compose d'une fenêtre ancrable et d'un contrôle d'outil. J'essaie de garder un journal des plantages d'ArcGIS à cause de mon outil. Et j'obtiens un certain succès sur la gestion des exceptions de niveau supérieur en utilisant Application.ThreadException. Étant donné que l'exception de thread ne fonctionne que pour le thread d'interface utilisateur, après l'instanciation de la fenêtre ancrable, toute exception pouvant entraîner une panne d'ArcGIS, elle le détecte, mais elle ne fonctionne pas avant l'instanciation de la fenêtre ancrable.

    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 ");
        }
    }

Cela fait la gestion des exceptions de niveau supérieur après l'instanciation de l'interface utilisateur