Handler nieobsługiwany wyjątek w .NET 1.1

głosy
23

Ja utrzymywanie aplikacji .NET 1.1 i jedną z rzeczy, jakie otrzymała zadanie jest upewnienie się, że użytkownik nie widzi żadnych nieprzyjaznych powiadomienia o błędach.

Dodałem do ładowarki Application.ThreadExceptioni AppDomain.CurrentDomain.UnhandledException, które nie sprawdzony. Moim problemem jest to, że nadal jest wyświetlana średnia dialogowe błędu CLR (przed obsługi wyjątku nazywa).

Jeff mówi o tym problemie na swoim blogu tutaj i tutaj . Ale nie ma rozwiązania. Więc co jest standardowym sposobem w .NET 1.1 do obsługi niezłapane wyjątki i wyświetlić okno dialogowe przyjazne?

odpowiedź Jeffa został oznaczony jako poprawnej odpowiedzi, ponieważ łącze zapewniał on ma najbardziej kompletne informacje na temat tego, co jest wymagane.

Utwórz 04/08/2008 o 02:15
źródło użytkownik
W innych językach...                            


5 odpowiedzi

głosy
3

Jest to aplikacja konsoli lub aplikacji Windows Forms? Jeśli jest to aplikacja .NET 1.1 konsola jest, niestety, przez design - to potwierdzone przez dev MSFT w drugim poście masz odwołanie :

BTW, na mojej maszynie 1.1 przykład z MSDN ma spodziewanych rezultatów; to tylko, że druga linia nie pojawi się dopiero po dołączeniu debuggera (lub nie). W v2 mamy odwrócenie rzeczy wokół tak, że Zdarzenie UnhandledException przed attache debugger, który wydaje się być to, co większość ludzi oczekuje.

To brzmi jak .NET 2.0 robi to lepiej (dzięki Bogu), ale szczerze mówiąc, nigdy nie miałem czasu, aby wrócić i sprawdzić.

Odpowiedział 04/08/2008 o 03:45
źródło użytkownik

głosy
1

Jest to aplikacja Windows Forms. Wyjątki, które są objęte Application.ThreadException działać dobrze, a ja nie dostać brzydkie okno wyjątek .NET ( OKdo wypowiedzenia, Canceldo debugowania? Kto wymyślił, że ??).

I był już pewne wyjątki, które nie zostały wciągnięcia przez to i skończyło się na razie AppDomain.UnhandledException które powodowały problemy. Chyba najbardziej przykuła tych wyjątków, a ja umieszczanie ich w naszym ładnym pudełku błędu teraz.

Więc będę tylko mieć nadzieję, że nie są jeszcze inne okoliczności, które mogłyby spowodować wyjątki nie być złapany przez przewodnika Application.ThreadException.

Odpowiedział 04/08/2008 o 03:54
źródło użytkownik

głosy
11

Och, w Windows Forms na pewno powinien być w stanie zmusić go do pracy. Jedyną rzeczą, którą musisz uważać na to wszystko dzieje się na różnych wątkach.

Mam starą artykuł kod projektu tutaj co powinno pomóc:

User Friendly Obsługa wyjątków

Odpowiedział 04/08/2008 o 05:31
źródło użytkownik

głosy
4

AppDomain.UnhandledException to wydarzenie , a nie globalny obsługi wyjątku. Oznacza to, do czasu, gdy zostanie podniesiony, aplikacja jest już w drodze do ścieku, a tam nic nie można zrobić, z wyjątkiem robi porządki i błędzie logowania.

Co się stało za kulisami jest to: Ramy wykryty wyjątek, podszedł stos wywołań do samego szczytu, nie znaleziono koparki, która odzyskania od błędów, więc nie był w stanie określić, czy to aby kontynuować wykonanie bezpieczne. Więc zaczęło sekwencji zamykania i wystrzelił w górę to wydarzenie jako uprzejmości wam więc można płacić szacunek do już skazane procesu. Dzieje się tak, gdy wyjątek nieobsłużonego pozostaje w głównym wątku.

Nie ma jednopunktowy rozwiązanie tego rodzaju błędu. Trzeba położyć obsługi prawdziwy wyjątek (blok catch) powyżej wszystkich miejscach, w których występuje ten błąd i przesyła go do (na przykład) globalnej metody obsługi / klasy, która określi, czy jest to bezpieczne po prostu zgłosić i dalej, na podstawie rodzaj i / lub zawartość wyjątku.

Edit: Jest możliwe, aby wyłączyć (= siekać) mechanizm raportowania błędów w systemie Windows zbudowany tak obowiązkowego „crash i spalić” dialogowe nie zostanie wyświetlone, gdy aplikacja idzie w dół. Jednak ta staje się skuteczna dla wszystkich aplikacji w systemie, a nie tylko własne.

Odpowiedział 04/08/2008 o 11:20
źródło użytkownik

głosy
5

Nieobsługiwany wyjątek zachowanie w 1.x NET aplikacji Windows Forms zależy od:

  • Rodzaj nici że zwrócił wyjątek
  • Czy wystąpił podczas przetwarzania wiadomości okna
  • Czy debugger został dołączony do procesu
  • Ustawienie rejestru DbgJitDebugLaunchSetting
  • Flaga jitDebugging w app.config
  • Czy overrode Windows Forms obsługi wyjątku
  • Czy zdarzenie wyjątku CLR za ty obchodzić
  • Faza księżyca

Domyślne zachowanie nieobsłużonych wyjątków jest:

  • Jeśli wyjątek występuje w głównym wątku podczas pompowania wiadomości okiennych, to przechwycone przez procedurę obsługi wyjątków systemu Windows Forms.
  • Jeśli wyjątek występuje w głównym wątku podczas pompowania wiadomości okienne, będzie zakończyć proces aplikacji, o ile nie zostanie przechwycony przez procedurę obsługi wyjątków systemu Windows Forms.
  • Jeśli wyjątek występuje na ręcznym, puli wątków lub wątku finalizatora, to połknięte przez CLR.

Punkty kontaktu dla nieobsłużonego wyjątku są:

  • Windows Forms obsługi wyjątku.
  • przełączyć rejestru JIT-debug DbgJitDebugLaunchSetting.
  • CLR zdarzenie nieobsłużonego wyjątkiem.

Wbudowana obsługa wyjątków Formularz Windows ma domyślnie co następuje:

  • Chwyta się unhandled wyjątek, kiedy:
    • Wyjątkiem jest głównym gwintem i bez debugera przymocowane.
    • Wyjątek występuje w trakcie przetwarzania wiadomości okno.
    • jitDebugging = false w app.config.
  • Pokazuje okno dialogowe do użytkownika i uniemożliwia zakończenie aplikacji.

Można wyłączyć ten ostatni zachowanie, ustawiając jitDebugging = true w app.config. Ale pamiętaj, że to może być Twoja ostatnia szansa, aby zatrzymać aplikację zakończenie. Więc następnym krokiem do połowu nieobsługiwany wyjątek rejestruje dla Application.ThreadException zdarzeń, np:

Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);

Uwaga rejestru ustawienia DbgJitDebugLaunchSetting pod HKEY_LOCAL_MACHINE \ Software.NetFramework. To ma jedną z trzech wartości, z których jestem świadomy:

  • 0: wyświetla okno dialogowe z pytaniem użytkownika „debug lub zakończyć”.
  • 1: pozwala na wyjątek przez CLR do czynienia.
  • 2: uruchamia debugger określone w kluczu rejestru DbgManagedDebugger.

W Visual Studio, przejdź do menu NarzędziaOpcjeDebugowanieJIT ustawienie tego klucza na 0 lub 2. Ale wartość 1 jest zwykle najlepiej na komputerze końcowego użytkownika. Zauważ, że ten klucz rejestru oddziałuje przed zdarzeniem nieobsługiwany wyjątek CLR.

To ostatnie wydarzenie jest twoja ostatnia szansa, aby zalogować nieobsługiwany wyjątek. To spowodowało, zanim twoi Wreszcie bloki wykonane. Można przechwycić to wydarzenie w następujący sposób:

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);
Odpowiedział 20/09/2008 o 16:52
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more