Przetwarzanie nieobsługiwanych wyjątków (C#)

Autor: Scott Mitchell

Wyświetl lub pobierz przykładowy kod (jak pobrać)

W przypadku wystąpienia błędu czasu wykonywania w aplikacji internetowej w środowisku produkcyjnym ważne jest, aby powiadomić dewelopera i zarejestrować błąd, aby mógł zostać zdiagnozowany w późniejszym momencie. Ten samouczek zawiera przegląd tego, jak ASP.NET przetwarza błędy środowiska uruchomieniowego, oraz przedstawia sposób wykonywania niestandardowego kodu za każdym razem, gdy nieobsługiwany wyjątek przechodzi do środowiska uruchomieniowego ASP.NET.

Wprowadzenie

Gdy w aplikacji ASP.NET wystąpi nieobsługiwany wyjątek, jest on propagowany do środowiska uruchomieniowego ASP.NET, które powoduje wystąpienie zdarzenia Error i wyświetla odpowiednią stronę błędu. Istnieją trzy różne typy stron błędów: Żółty ekran czasu wykonywania śmierci (YSOD); Szczegóły wyjątku YSOD; i niestandardowe strony błędów. W poprzednim samouczku skonfigurowaliśmy aplikację tak, aby korzystała z niestandardowej strony błędu dla użytkowników zdalnych oraz informacyjnej strony YSOD o szczegółach wyjątku dla użytkowników uzyskujących dostęp lokalnie.

Użycie przyjaznej dla człowieka niestandardowej strony błędu zgodnej z wyglądem i działaniem witryny jest preferowane do domyślnego błędu czasu wykonania YSOD, ale wyświetlanie niestandardowej strony błędu jest tylko jedną częścią kompleksowego rozwiązania do obsługi błędów. W przypadku wystąpienia błędu w aplikacji w środowisku produkcyjnym ważne jest, aby deweloperzy otrzymywali powiadomienia o błędzie, aby mogli odkryć przyczynę wyjątku i rozwiązać go. Ponadto należy zarejestrować szczegóły błędu, aby można je było zbadać i zdiagnozować w późniejszym momencie.

W tym samouczku pokazano, jak uzyskać dostęp do szczegółów nieobsługiwanego wyjątku, aby można było je zarejestrować i powiadomić dewelopera. Dwa następne samouczki po tym eksplorują biblioteki rejestrowania błędów, które, po krótkiej konfiguracji, automatycznie powiadomią deweloperów o błędach czasu wykonywania i zarejestrują ich szczegóły.

Wykonywanie kodu po wystąpieniuErrorzdarzenia

Zdarzenia zapewniają obiektom mechanizm do sygnalizowania, że wystąpiło coś interesującego, oraz umożliwiają innym obiektom wykonanie kodu w odpowiedzi. Jako deweloper ASP.NET jesteś przyzwyczajony do myślenia pod względem wydarzeń. Jeśli chcesz uruchomić kod, gdy odwiedzający kliknie określony przycisk, utworzysz procedurę obsługi zdarzeń dla zdarzenia tego przycisku Click i umieść tam kod. Ze względu na to, że środowisko uruchomieniowe ASP.NET zgłasza zdarzenie Error za każdym razem, gdy wystąpi nieobsługiwany wyjątek, oznacza to, że kod rejestrujący szczegóły błędu powinien zostać umieszczony w procedurze obsługi zdarzeń. Jak jednak utworzyć program obsługi zdarzeń dla Error zdarzenia?

Zdarzenie Error jest jednym z wielu zdarzeń w HttpApplication klasie , które są wywoływane na określonych etapach potoku HTTP w okresie istnienia żądania. Na przykład zdarzenie HttpApplication klasy BeginRequest jest wywoływane na początku każdego żądania; jego AuthenticateRequest zdarzenie jest zgłaszane, gdy moduł zabezpieczeń zidentyfikuje żądającego. Te HttpApplication zdarzenia umożliwiają deweloperowi strony wykonywanie logiki niestandardowej w różnych punktach istnienia żądania.

Programy obsługi zdarzeń dla zdarzeń HttpApplication można umieścić w specjalnym pliku o nazwie Global.asax. Aby utworzyć ten plik w witrynie internetowej, dodaj nowy element do katalogu głównego witryny internetowej przy użyciu szablonu Global Application Class (Klasa aplikacji globalnej) o nazwie Global.asax.

Rysunek 1. Dodawanie Global.asax do aplikacji internetowej
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Zawartość i struktura pliku utworzonego Global.asax przez program Visual Studio różnią się nieznacznie w zależności od tego, czy używasz projektu aplikacji internetowej (WAP) lub projektu witryny sieci Web (WSP). W przypadku aplikacji WAP element Global.asax jest implementowany jako dwa oddzielne pliki — Global.asax i Global.asax.cs. Plik Global.asax zawiera tylko dyrektywę @Application, która odwołuje się do pliku .cs; interesujące nas programy obsługi zdarzeń są zdefiniowane w pliku Global.asax.cs. W przypadku dostawców usług WSP tworzony jest tylko jeden plik, Global.asaxa programy obsługi zdarzeń są definiowane <script runat="server"> w bloku.

Plik Global.asax utworzony w aplikacji WAP przez szablon globalnej klasy aplikacji programu Visual Studio zawiera programy obsługi zdarzeń o nazwach Application_BeginRequest, Application_AuthenticateRequesti Application_Error, które są procedurami obsługi zdarzeń odpowiednio HttpApplication dla zdarzeń BeginRequest, AuthenticateRequesti Error. Istnieją również programy obsługi zdarzeń o nazwach Application_Start, , Session_StartApplication_Endi Session_End, które są procedurami obsługi zdarzeń, które są uruchamiane po uruchomieniu aplikacji internetowej, po uruchomieniu nowej sesji, po zakończeniu aplikacji i zakończeniu sesji, odpowiednio. Global.asax Plik utworzony w programie WSP przez program Visual Studio zawiera tylko Application_Errorprogramy obsługi zdarzeń , Application_Start, Session_Start, Application_Endi Session_End .

Programy obsługi zdarzeń utworzone przez szablon globalnej klasy aplikacji programu Visual Studio nie są wyczerpujące. Program obsługi zdarzenia można dodać dla dowolnego HttpApplication zdarzenia, nazywając go Application_EventName. Możesz na przykład dodać następujący kod do Global.asax pliku, aby utworzyć program obsługi zdarzeń dla AuthorizeRequest zdarzenia:

protected void Application_AuthorizeRequest(object sender, EventArgs e)
{
    // Event handler code
}

Podobnie można usunąć wszystkie programy obsługi zdarzeń utworzone przez szablon Globalny klas aplikacji, które nie są potrzebne. W tym samouczku potrzebujemy tylko procedury obsługi zdarzenia Error; możesz usunąć inne procedury obsługi zdarzeń z pliku Global.asax.

Pobieranie informacji o nieobsługiwanym wyjątku

W tym momencie mamy plik Global.asax z procedurą Application_Error obsługi zdarzeń. Gdy ta procedura obsługi zdarzeń jest wykonywana, musimy powiadomić dewelopera o błędzie i zarejestrować jego szczegóły. Aby wykonać te zadania, najpierw musimy określić szczegóły zgłoszonego wyjątku. Użyj metody obiektu ServerGetLastError, aby pobrać szczegóły nieobsługiwanego wyjątku, który spowodował wyzwolenie zdarzenia Error.

protected void Application_Error(object sender, EventArgs e)
{
    // Get the error details
    HttpException lastErrorWrapper = 
        Server.GetLastError() as HttpException;
}

Metoda GetLastError zwraca obiekt typu Exception, który jest typem podstawowym dla wszystkich wyjątków w programie .NET Framework. Jednak w powyższym kodzie rzutuję zwrócony przez GetLastError obiekt Exception na obiekt typu HttpException. Error Jeśli zdarzenie jest wyzwalane, ponieważ wystąpił wyjątek podczas przetwarzania zasobu ASP.NET, wyjątek, który został zgłoszony, jest opakowany w obiekcie HttpException. Aby uzyskać rzeczywisty wyjątek, który poprzedzał zdarzenie Error, użyj InnerException właściwości . Error Jeśli zdarzenie zostało zgłoszone z powodu wyjątku opartego na protokole HTTP, takiego jak żądanie dla nieistniejącej strony, HttpException zgłaszany jest wyjątek, ale nie ma wewnętrznego wyjątku.

Poniższy kod używa elementu GetLastErrormessage, aby pobrać informacje o wyjątku, który wyzwolił zdarzenie Error, przechowując element HttpException w zmiennej o nazwie lastErrorWrapper. Następnie przechowuje typ, komunikat i ślad stosu wywołań wyjątku źródłowego w trzech zmiennych typu string, sprawdzając, czy lastErrorWrapper to rzeczywisty wyjątek, który wyzwolił Error zdarzenie (w przypadku wyjątków opartych na protokole HTTP), czy jest to tylko otoczka wyjątku, który wystąpił podczas przetwarzania żądania.

protected void Application_Error(object sender, EventArgs e)
{
    // Get the error details
    HttpException lastErrorWrapper = 
        Server.GetLastError() as HttpException;

    Exception lastError = lastErrorWrapper;
    if (lastErrorWrapper.InnerException != null)
        lastError = lastErrorWrapper.InnerException;

    string lastErrorTypeName = lastError.GetType().ToString();
    string lastErrorMessage = lastError.Message;
    string lastErrorStackTrace = lastError.StackTrace;
}

W tym momencie masz wszystkie informacje potrzebne do pisania kodu, który będzie rejestrować szczegóły wyjątku w tabeli bazy danych. Możesz utworzyć tabelę bazy danych z kolumnami dla każdego z interesujących cię szczegółów błędu — typ, komunikat, ślad stosu itd. — wraz z innymi przydatnymi informacjami, takimi jak adres URL żądanej strony i nazwa aktualnie zalogowanego użytkownika. W procedurze Application_Error obsługi zdarzeń połączysz się z bazą danych i wstawisz rekord do tabeli. Podobnie możesz dodać kod, aby powiadomić dewelopera o błędzie za pośrednictwem poczty e-mail.

Biblioteki rejestrowania błędów zbadane w dwóch następnych samouczkach zawierają takie funkcje gotowe do użycia, więc nie ma potrzeby samodzielnego kompilowania tego rejestrowania błędów i powiadamiania. Aby jednak zilustrować, że Error zdarzenie jest zgłaszane i że Application_Error program obsługi zdarzeń może służyć do rejestrowania szczegółów błędu i powiadamiania dewelopera, dodajmy kod, który powiadamia dewelopera o wystąpieniu błędu.

Powiadamianie dewelopera o wystąpieniu nieobsługiwanego wyjątku

Gdy w środowisku produkcyjnym wystąpi nieobsługiwany wyjątek, ważne jest, aby zaalarmować zespół deweloperów, aby mógł ocenić błąd i określić, jakie działania należy podjąć. Jeśli na przykład wystąpi błąd podczas nawiązywania połączenia z bazą danych, musisz dokładnie sprawdzić parametry połączenia i, być może, otworzyć bilet pomocy technicznej w firmie hostingowej internetowej. Jeśli wystąpił wyjątek z powodu błędu programowania, może być konieczne dodanie dodatkowego kodu lub logiki walidacji, aby zapobiec takim błędom w przyszłości.

Klasy programu .NET Framework w System.Net.Mail przestrzeni nazw ułatwiają wysyłanie wiadomości e-mail. Klasa MailMessage reprezentuje wiadomość e-mail i ma właściwości, takie jak To, , FromSubject, Body, i Attachments. Obiekt SmtpClass jest używany do wysyłania MailMessage przy użyciu określonego serwera SMTP; ustawienia serwera SMTP można określić programowo lub deklaratywnie w <system.net> elemencie w Web.config file obiekcie. Aby uzyskać więcej informacji na temat wysyłania wiadomości e-mail w aplikacji ASP.NET, zapoznaj się z moim artykułem Wysyłanie e-maili z witryny ASP.NET Web Pages oraz System.Net.Mail.

Dodaj następujący kod do Application_Error programu obsługi zdarzeń, aby wysłać deweloperowi wiadomość e-mail po wystąpieniu błędu:

void Application_Error(object sender, EventArgs e)
{
    // Get the error details
    HttpException lastErrorWrapper = 
        Server.GetLastError() as HttpException;

    Exception lastError = lastErrorWrapper;
    if (lastErrorWrapper.InnerException != null)
        lastError = lastErrorWrapper.InnerException;

    string lastErrorTypeName = lastError.GetType().ToString();
    string lastErrorMessage = lastError.Message;
    string lastErrorStackTrace = lastError.StackTrace;

    const string ToAddress = "support@example.com";
    const string FromAddress = "support@example.com";
    const string Subject = "An Error Has Occurred!";
    
    // Create the MailMessage object
    MailMessage mm = new MailMessage(FromAddress, ToAddress);
    mm.Subject = Subject;
    mm.IsBodyHtml = true;
    mm.Priority = MailPriority.High;
    mm.Body = string.Format(@"
<html>
<body>
  <h1>An Error Has Occurred!</h1>
  <table cellpadding=""5"" cellspacing=""0"" border=""1"">
  <tr>
  <tdtext-align: right;font-weight: bold"">URL:</td>
  <td>{0}</td>
  </tr>
  <tr>
  <tdtext-align: right;font-weight: bold"">User:</td>
  <td>{1}</td>
  </tr>
  <tr>
  <tdtext-align: right;font-weight: bold"">Exception Type:</td>
  <td>{2}</td>
  </tr>
  <tr>
  <tdtext-align: right;font-weight: bold"">Message:</td>
  <td>{3}</td>
  </tr>
  <tr>
  <tdtext-align: right;font-weight: bold"">Stack Trace:</td>
  <td>{4}</td>
  </tr> 
  </table>
</body>
</html>",
        Request.RawUrl,
        User.Identity.Name,
        lastErrorTypeName,
        lastErrorMessage,
        lastErrorStackTrace.Replace(Environment.NewLine, "<br />"));

    // Attach the Yellow Screen of Death for this error   
    string YSODmarkup = lastErrorWrapper.GetHtmlErrorMessage();
    if (!string.IsNullOrEmpty(YSODmarkup))
    {
        Attachment YSOD = 
            Attachment.CreateAttachmentFromString(YSODmarkup, "YSOD.htm");
        mm.Attachments.Add(YSOD);
    }

    // Send the email
    SmtpClient smtp = new SmtpClient();
    smtp.Send(mm);
}

Chociaż powyższy kod jest dość długi, większość z niego tworzy kod HTML wyświetlany w wiadomości e-mail wysłanej do dewelopera. Kod rozpoczyna się od odwołania do HttpException zwracanego przez metodę GetLastError (lastErrorWrapper). Rzeczywisty wyjątek zgłoszony przez żądanie jest pobierany za pośrednictwem lastErrorWrapper.InnerException i jest przypisywany do zmiennej lastError. Informacje o typie, komunikacie i śledzeniu stosu są pobierane z lastError i przechowywane w trzech zmiennych typu string.

Następnie obiekt o nazwie mm zostanie utworzony MailMessage. Treść wiadomości e-mail jest sformatowana w formacie HTML i wyświetla adres URL żądanej strony, nazwę aktualnie zalogowanego użytkownika oraz informacje o wyjątku (typ, wiadomość i ślad stosu). Jedną z ciekawych kwestii dotyczących klasy HttpException jest to, że można wygenerować kod HTML używany do tworzenia Żółtego Ekranu Szczegółów Wyjątku (YSOD), wywołując metodę GetHtmlErrorMessage. Ta metoda jest używana tutaj do pobierania znacznika YSOD szczegółów wyjątku i dodawania go do wiadomości e-mail jako załącznika. Uwaga: jeśli wyjątek, który wyzwolił Error zdarzenie, był wyjątkiem HTTP (takim jak żądanie dotyczące nieistniejącej strony), to GetHtmlErrorMessage metoda zwróci null.

Ostatnim krokiem jest wysłanie polecenia MailMessage. Jest to wykonywane przez utworzenie nowej SmtpClient metody i wywołanie jej Send metody.

Przy użyciu tego kodu, za każdym razem gdy pojawia się błąd, deweloper otrzymuje wiadomość e-mail, która podsumowuje błąd i zawiera kod YSOD. W poprzednim samouczku przedstawiliśmy błąd środowiska uruchomieniowego, odwiedzając Genre.aspx i przekazując nieprawidłową ID wartość za pośrednictwem ciągu zapytania, na przykład Genre.aspx?ID=foo. Odwiedzenie strony, na której znajduje się plik Global.asax, zapewnia takie same wrażenia użytkownika, jak w poprzednim samouczku — w środowisku deweloperskim będziesz nadal widzieć żółty ekran śmierci z szczegółami wyjątku, podczas gdy w środowisku produkcyjnym pojawi się niestandardowa strona błędu. Oprócz tego istniejącego zachowania deweloper otrzymuje wiadomość e-mail.

Rysunek 2 przedstawia wiadomość e-mail odebraną podczas wizyty Genre.aspx?ID=foo. Treść wiadomości e-mail zawiera podsumowanie informacji o wyjątku, podczas gdy YSOD.htm załącznik wyświetla zawartość wyświetlaną w module Szczegóły wyjątku YSOD (zobacz Rysunek 3).

Rysunek 2. Deweloper otrzymuje powiadomienie e-mail za każdym razem, gdy występuje nieobsługiwany wyjątek
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Rysunek 3. Powiadomienie e-mail zawiera szczegóły wyjątku YSOD jako załącznik
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Jakie są korzyści z używania niestandardowej strony błędu?

W tym samouczku pokazano, jak używać Global.asax i uchwytu zdarzeń Application_Error do wykonywania kodu, gdy wystąpi nieobsługiwany wyjątek. W szczególności użyliśmy tej procedury obsługi zdarzeń, aby powiadomić dewelopera o błędzie; Możemy ją rozszerzyć, aby rejestrować szczegóły błędu w bazie danych. Obecność programu obsługi zdarzeń Application_Error nie ma wpływu na środowisko użytkownika końcowego. Nadal widzą skonfigurowaną stronę błędu, za każdym razem są to szczegóły błędu YSOD, błąd czasu wykonania YSOD bądź niestandardowa strona błędu.

To naturalne, że zastanawiamy się, czy Global.asax plik i Application_Error zdarzenie są konieczne przy korzystaniu z niestandardowej strony błędu. Gdy wystąpi błąd, użytkownikowi zostanie wyświetlona niestandardowa strona błędu, więc dlaczego nie możemy umieścić kodu w celu powiadomienia dewelopera i zarejestrowania szczegółów błędu w klasie code-behind niestandardowej strony błędu? Chociaż z pewnością możesz dodać kod do klasy zaplecza strony niestandardowego błędu, nie masz dostępu do szczegółów wyjątku, który wyzwolił zdarzenie Error podczas korzystania z techniki, którą omówiliśmy w poprzednim samouczku. Wywołanie metody GetLastError ze strony błędu niestandardowego zwraca Nothing.

Przyczyną tego zachowania jest to, że strona błędu niestandardowego jest osiągana za pośrednictwem przekierowania. Gdy nieobsługiwany wyjątek dociera do środowiska uruchomieniowego ASP.NET aparat ASP.NET zgłasza zdarzenie Error (które wykonuje Application_Error program obsługi zdarzeń), a następnie przekierowuje użytkownika do niestandardowej strony błędu, wydając polecenie Response.Redirect(customErrorPageUrl). Metoda Response.Redirect wysyła odpowiedź do klienta z kodem stanu HTTP 302, nakazując przeglądarce żądanie nowego adresu URL, a mianowicie niestandardową stronę błędu. Następnie przeglądarka automatycznie żąda tej nowej strony. Możesz stwierdzić, że żądano niestandardowej strony błędu oddzielnie od strony, na której pochodzi błąd, ponieważ pasek adresu przeglądarki zmienia się na niestandardowy adres URL strony błędu (zobacz Rysunek 4).

Rysunek 4. Gdy wystąpi błąd, przeglądarka zostanie przekierowana do niestandardowego adresu URL strony błędu
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Efekt netto polega na tym, że żądanie, w którym wystąpił nieobsługiwany wyjątek, kończy się, gdy serwer odpowiada za pomocą przekierowania HTTP 302. Kolejne żądanie do niestandardowej strony błędu jest zupełnie nowym żądaniem; do tego momentu aparat ASP.NET odrzucił informacje o błędzie, a ponadto nie ma możliwości skojarzenia nieobsługiwanego wyjątku w poprzednim żądaniu z nowym żądaniem dla niestandardowej strony błędu. Dlatego GetLastError zwraca null przy wywołaniu z niestandardowej strony błędu.

Możliwe jest jednak wykonanie niestandardowej strony błędu w trakcie tego samego żądania, które spowodowało błąd. Metoda Server.Transfer(url) przenosi wykonanie do określonego adresu URL i przetwarza je w ramach tego samego żądania. pl-PL: Kod programu w obsłudze zdarzeń Application_Error można przenieść do klasy code-behind niestandardowej strony błędu, zastępując go w Global.asax następującym kodem:

protected void Application_Error(object sender, EventArgs e)
{
    // Transfer the user to the appropriate custom error page
    HttpException lastErrorWrapper = 
        Server.GetLastError() as HttpException;

    if (lastErrorWrapper.GetHttpCode() == 404)
    {
        Server.Transfer("~/ErrorPages/404.aspx");
    }
    else
    {
        Server.Transfer("~/ErrorPages/Oops.aspx");
    }
}

Teraz, gdy wystąpi nieobsługiwany wyjątek, Application_Error program obsługi zdarzeń przesyła kontrolkę do odpowiedniej niestandardowej strony błędu na podstawie kodu stanu HTTP. Ponieważ kontrolka została przeniesiona, niestandardowa strona błędu ma dostęp do nieobsługiwanych informacji o wyjątku za pośrednictwem Server.GetLastError i może powiadomić dewelopera o błędzie i zarejestrować jego szczegóły. Wywołanie Server.Transfer zapobiega, aby mechanizm ASP.NET przekierowywał użytkownika do niestandardowej strony błędu. Zamiast tego zawartość niestandardowej strony błędu jest zwracana jako odpowiedź na stronę, która wygenerowała błąd.

Podsumowanie

Gdy w aplikacji internetowej ASP.NET wystąpi nieobsługiwany wyjątek, środowisko uruchomieniowe ASP.NET zgłasza Error zdarzenie i wyświetla skonfigurowaną stronę błędu. Możemy powiadomić dewelopera o błędzie, zarejestrować jego szczegóły lub przetworzyć go w inny sposób, tworząc procedurę obsługi zdarzeń dla zdarzenia Błąd. Istnieją dwa sposoby tworzenia procedury obsługi zdarzeń dla HttpApplication zdarzeń, takich jak Error: w Global.asax pliku lub z modułu HTTP. W tym samouczku pokazano, jak utworzyć Error program obsługi zdarzeń w Global.asax pliku, który powiadamia deweloperów o błędzie za pomocą wiadomości e-mail.

Tworzenie procedury obsługi zdarzeń Error jest przydatne, jeśli musisz przetworzyć nieobsługiwane wyjątki w sposób unikatowy lub dostosowany. Jednak utworzenie własnej Error procedury obsługi zdarzeń w celu zarejestrowania wyjątku lub powiadomienia dewelopera nie jest najbardziej efektywnym użyciem czasu, ponieważ istnieje już bezpłatne i łatwe w użyciu bibliotek rejestrowania błędów, które można skonfigurować w ciągu kilku minut. Dwa następne samouczki badają dwie takie biblioteki.

Szczęśliwe programowanie!

Dalsze informacje

Aby uzyskać więcej informacji na temat tematów omówionych w tym samouczku, zapoznaj się z następującymi zasobami:

• ASP.NET moduły HTTP i programy obsługi HTTP — omówienie
• Łagodne reagowanie na nieobsługiwane wyjątki – przetwarzanie nieobsługiwanych wyjątków
• HttpApplication Klasa i obiekt aplikacji ASP.NET
• Programy obsługi HTTP i moduły HTTP w ASP.NET
• Wysyłanie wiadomości e-mail w ASP.NET
• Global.asax Opis pliku
• Używanie modułów HTTP i programów obsługi do tworzenia składników ASP.NET z możliwością podłączania
• Praca z plikiem ASP.NET Global.asax
• Praca z HttpApplication instancjami