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

10

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.

blah238
la source
1
Juste pour info: voici un lien essayant de résoudre ce problème un peu à esri
Erik L
@ blah238 Qu'avez-vous fait pour résoudre votre problème? Pouvez-vous me donner quelques conseils pour gérer les exceptions non gérées?
Emi
Mettez un gestionnaire d'exceptions à chaque point d'entrée de votre code.
blah238
A chaque point d'entrée? !! Il n'y a pas d'autre moyen de le gérer de haut niveau?
Emi
C'est ma compréhension, oui. Voir le lien @baens ci-dessus si vous souhaitez que cela soit amélioré.
blah238

Réponses:

7

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.

Troy Schmidt
la source
Merci, c'est ce à quoi je m'attendais car tous les échantillons ESRI le font de la même manière.
blah238
@Troy Schmidt pouvez-vous s'il vous plaît me donner un pointeur sur quand j'utilise une fenêtre ancrable, comment puis-je gérer les exceptions non gérées? Et d'où et que dois-je "jeter"?
Emi
2

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

Emi
la source
Intéressant, merci d'avoir posté vos résultats. Je vais devoir jouer avec ça. En particulier, je me demande si la fenêtre ancrable est vraiment nécessaire ou si elle pourrait être configurée dans une extension.
blah238
@ blah238 Thread.Exception fonctionne également lorsque je le mets sur la méthode onclick du bouton. Je pense que cela fonctionne pour tout contrôle qui interagit avec l'interface utilisateur.
Emi