Dodatek ArcGIS 10: Obsługa wyjątków na najwyższym poziomie

10

Dodatek ArcGIS 10, nad którym pracuję, jest dość prosty - tylko kontrolka narzędzia i okno do dokowania. Zajmuję się konkretnymi wyjątkami, które, jak się spodziewam, występują u źródła i rzucają wszystko inne, ale jaka jest najlepsza praktyka obsługi tych nieoczekiwanych wyjątków w ramach dodatków?

Obecnie właśnie robię a catch (System.Exception ex)i pokazuję to w MessageBox w każdej metodzie, która nie ma metody wyższego poziomu, w której mogłabym to obsłużyć, ale nie wydaje się to najlepszą praktyką (i oczywiście FxCop marudzi o tym).

Czy w środowisku dodatków ArcGIS 10 jest jakaś funkcja umożliwiająca podłączenie obsługi wyjątków najwyższego poziomu, na przykład do zdarzeń Application.ThreadExceptionlub AppDomain.UnhandledException?

Widząc, że dodatki to tylko biblioteki klas, a nie aplikacje bez dostępu do kodu startowego aplikacji bazowej (z tego, co zbieram, te zdarzenia muszą być podłączone na bardzo wczesnym etapie procesu uruchamiania), zgaduję, że nie, ale pomyślałem Zapytałbym, czy jakikolwiek ekspert ma jakieś sugestie, jak „nieoczekiwane” wyjątki powinny być obsługiwane w dodatkach.

blah238
źródło
1
Tylko do waszej informacji: tutaj jest link, który próbuje to trochę naprawić w esri
Erik L
@ blah238 Co zrobiłeś, aby rozwiązać swój problem? Czy możesz prosić o wskazówki dotyczące nieobsługiwanych wyjątków?
Emi
Umieść procedurę obsługi wyjątków w każdym punkcie wejścia do swojego kodu.
blah238
W każdym punkcie wejścia? !! Nie ma innego sposobu, aby sobie z tym poradzić z najwyższego poziomu?
Emi
Tak rozumiem. Zobacz link @baens powyżej, jeśli chcesz to poprawić.
blah238,

Odpowiedzi:

7

O ile mogę powiedzieć, wdrażasz obsługę błędów, którą ESRI obecnie przedstawia jako najlepszą praktykę. Jeśli chcesz uchwycić nieobsługiwane wyjątki aplikacji ( ArcMap ), możesz potencjalnie wyświetlać komunikaty o błędach, które nie były częścią Twojego AddIn. Większość twoich AddInsów będzie prawdopodobnie przyciskami, a te naprawdę mają tylko dwie główne trasy, które wychwytują i wyświetlają nieoczekiwane błędy ( onClick i onUpdate ).

Pamiętaj tylko, aby użyć „ rzut ” zamiast „ rzut ex ”. Różnica jest niewielka, ale powoduje zachowanie linii błędu, gdy wyskakuje z wywoływanych funkcji.

Troy Schmidt
źródło
Dzięki, właśnie tego się spodziewałem, ponieważ wszystkie próbki ESRI robią to w ten sam sposób.
blah238
@Troy Schmidt, czy możesz podać mi wskaźnik, kiedy korzystam z dokowalnego okna, w jaki sposób mogę obsłużyć nieobsługiwane wyjątki? A skąd i co mam „Rzucać”?
Emi
2

Pracuję z dodatkiem ArcGIS. Mój dodatek składa się z dokowalnego okna i kontrolki narzędzia. Staram się prowadzić dziennik awarii ArcGIS z powodu mojego narzędzia. I odnoszę sukcesy w obsłudze wyjątków najwyższego poziomu za pomocą Application.ThreadException. Ponieważ wyjątek wątku działa tylko dla wątku interfejsu użytkownika, po utworzeniu okna dokowalnego każdy wyjątek, który może być przyczyną awarii ArcGIS, wychwytuje go, ale nie działa przed utworzeniem okna dokowalnego.

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

Umożliwia to obsługę wyjątków na najwyższym poziomie po utworzeniu interfejsu użytkownika

Emi
źródło
Ciekawe, dziękuję za opublikowanie swoich ustaleń. Będę musiał się z tym bawić. W szczególności zastanawiam się, czy dokowalne okno jest naprawdę konieczne, czy też można je ustawić w rozszerzeniu.
blah238
@ blah238 Thread.Exception działa również, gdy włączę metodę przycisku onclick. Myślę, że to działa na każdą kontrolę, która współdziała z interfejsem użytkownika.
Emi