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

Artykuł
11/08/2024

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 omówienie sposobu, w jaki ASP.NET przetwarza błędy środowiska uruchomieniowego i analizuje jeden sposób wykonywania niestandardowego kodu za każdym razem, gdy nieobsługiwany wyjątek bąbelkuje do środowiska uruchomieniowego ASP.NET.

Wprowadzenie

Gdy w aplikacji ASP.NET wystąpi nieobsługiwany wyjątek, jest on bąbelkowy do środowiska uruchomieniowego ASP.NET, który zgłasza Error zdarzenie 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 i YSOD szczegółów wyjątku dla użytkowników odwiedzających się 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 samouczki opisane w tym jednym z tych samouczków eksplorują biblioteki rejestrowania błędów, które po pewnym czasie konfiguracji automatycznie powiadomi deweloperów o błędach środowiska uruchomieniowego i zarejestruje ich szczegóły.

Uwaga

Informacje zbadane w tym samouczku są najbardziej przydatne, jeśli musisz przetworzyć nieobsługiwane wyjątki w sposób unikatowy lub dostosowany. W przypadkach, gdy musisz zarejestrować wyjątek i powiadomić dewelopera, użycie biblioteki rejestrowania błędów jest sposobem na przejście. Dwa następne samouczki zawierają omówienie dwóch takich bibliotek.

Wykonywanie kodu po wystąpieniu`Error`zdarzenia

Zdarzenia udostępniają obiekt mechanizm sygnalizujący, że wystąpił coś interesującego, a dla innego obiektu do wykonania 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, następuje kod rejestrowania szczegółów błędu, który będzie przechodził 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 HttpApplication zdarzenie klasyBeginRequest jest wywoływane na początku każdego żądania; jegoAuthenticateRequest zdarzenie jest zgłaszane, gdy moduł zabezpieczeń zidentyfikował osoby żądającej. 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 nie tylko dyrektywę @Application , która odwołuje się do .cs pliku; programy obsługi zdarzeń, których dotyczą, są zdefiniowane w Global.asax.cs pliku. 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 .

Uwaga

Podczas wdrażania aplikacji ASP.NET należy skopiować Global.asax plik do środowiska produkcyjnego. Plik Global.asax.cs utworzony w aplikacji WAP nie musi być kopiowany do środowiska produkcyjnego, ponieważ ten kod jest kompilowany do zestawu projektu.

Programy obsługi zdarzeń utworzone przez szablon globalnej klasy aplikacji programu Visual Studio nie są wyczerpujące. Program obsługi zdarzeń można dodać dla dowolnego HttpApplication zdarzenia, nazywając program obsługi Application_EventNamezdarzeń . 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 zdarzeń dla Error zdarzenia. Możesz usunąć inne programy obsługi zdarzeń z Global.asax pliku.

Uwaga

Moduły HTTP oferują inny sposób definiowania programów obsługi zdarzeń dla HttpApplication zdarzeń. Moduły HTTP są tworzone jako plik klasy, który można umieścić bezpośrednio w projekcie aplikacji internetowej lub rozdzielać na oddzielną bibliotekę klas. Ponieważ można je rozdzielić na bibliotekę klas, moduły HTTP oferują bardziej elastyczny i wielokrotnego użytku model do tworzenia HttpApplication procedur obsługi zdarzeń. Global.asax Podczas gdy plik jest specyficzny dla aplikacji internetowej, w której się znajduje, moduły HTTP można skompilować do zestawów, w tym momencie dodanie modułu HTTP do witryny internetowej jest tak proste, jak usunięcie zestawu w Bin folderze i zarejestrowanie modułu w programie Web.config. Ten samouczek nie obejmuje tworzenia i używania modułów HTTP, ale dwa biblioteki rejestrowania błędów używane w poniższych dwóch samouczkach są implementowane jako moduły HTTP. Aby uzyskać więcej informacji na temat zalet modułów HTTP, zobacz Using HTTP Modules and Handlers to Create Pluggable ASP.NET Components (Używanie modułów HTTP i procedur obsługi do tworzenia składników ASP.NET z możliwością podłączania).

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 GetLastError Server, aby pobrać szczegóły nieobsługiwanego wyjątku, który spowodował Error wyzwolenie zdarzenia.

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ę obiekt Exception zwrócony przez GetLastError obiekt do HttpException obiektu. 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 wewnętrzny, ale nie ma wyjątku wewnętrznego.

Poniższy kod używa elementu , GetLastErrormessage aby pobrać informacje o wyjątku, który wyzwolił Error zdarzenie, przechowując HttpException element w zmiennej o nazwie lastErrorWrapper. Następnie przechowuje typ, komunikat i ślad stosu wyjątku źródłowego w trzech zmiennych ciągów, sprawdzając, czy lastErrorWrapper jest to rzeczywisty wyjątek, który wyzwolił Error zdarzenie (w przypadku wyjątków opartych na protokole HTTP) lub jeśli jest to tylko otoka wyjątku, który został zgłoszony 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 obiektu przy użyciu określonego serwera SMTP. Ustawienia serwera SMTP można określić programowo lub deklaratywnie w <system.net> elemecie w Web.config fileobiekcie . Aby uzyskać więcej informacji na temat wysyłania wiadomości e-mail w aplikacji ASP.NET, zapoznaj się z artykułem Wysyłanie wiadomości e-mail z witryny ASP.NET stron sieci Web i System.Net.Mail.

Uwaga

Element <system.net> zawiera ustawienia serwera SMTP używane przez klasę SmtpClient podczas wysyłania wiadomości e-mail. Twoja firma hostingowa sieci Web prawdopodobnie ma serwer SMTP, którego można użyć do wysyłania wiadomości e-mail z aplikacji. Zapoznaj się z sekcją pomocy technicznej hosta internetowego, aby uzyskać informacje na temat ustawień serwera SMTP, których należy użyć w aplikacji internetowej.

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ływania HttpException się do zwracanego przez metodę GetLastError (lastErrorWrapper). Rzeczywisty wyjątek zgłoszony przez żądanie jest pobierany za pośrednictwem lastErrorWrapper.InnerException metody i jest przypisywany do zmiennej lastError. Informacje o typie, komunikacie i śledzeniu stosu są pobierane z lastError i przechowywane w trzech zmiennych ciągu.

Następnie zostanie MailMessage utworzony obiekt o nazwie mm . 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 HttpException klasy jest to, że można wygenerować kod HTML używany do tworzenia żółty ekran szczegółów wyjątku śmierci (YSOD), wywołując metodę GetHtmlErrorMessage. Ta metoda jest używana tutaj do pobierania znaczników YSOD szczegółów wyjątku i dodawania go do wiadomości e-mail jako załącznika. Jedno słowo ostrożności: jeśli wyjątek, który wyzwolił Error zdarzenie, był wyjątkiem opartym na protokole HTTP (takim jak żądanie dla nieistniejącej strony), GetHtmlErrorMessage metoda zwróci nullwartość .

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

Uwaga

Przed użyciem tego kodu w aplikacji internetowej należy zmienić wartości w ToAddress stałych i FromAddress na support@example.com dowolny adres e-mail, do którego ma zostać wysłana wiadomość e-mail z powiadomieniem o błędzie i z której pochodzi. Należy również określić ustawienia serwera SMTP w <system.net> sekcji w sekcji .Web.config Skontaktuj się z dostawcą hosta sieci Web, aby określić ustawienia serwera SMTP do użycia.

Przy użyciu tego kodu w dowolnym momencie pojawia się błąd, który deweloper wysyła 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. Przejście do strony z Global.asax plikiem w miejscu powoduje utworzenie tego samego środowiska użytkownika, co w poprzednim samouczku — w środowisku deweloperskim będziesz nadal widzieć żółty ekran śmierci szczegóły wyjątku, podczas gdy w środowisku produkcyjnym zostanie wyświetlona 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)

Co z używaniem niestandardowej strony błędu?

W tym samouczku pokazano, jak używać programu Global.asax obsługi zdarzeń i wykonywać kod po wystąpieniu Application_Error nieobsługiwanego wyjątku. 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, czy to szczegóły błędu YSOD, błąd czasu wykonania YSOD lub niestandardową stronę błędu.

To naturalne, aby zastanawiać się, czy Global.asax plik i Application_Error zdarzenie jest konieczne podczas korzystania z niestandardowej strony błędu. Gdy wystąpi błąd, użytkownik zostanie wyświetlona niestandardowa strona błędu, dlatego nie możemy umieścić kodu w celu powiadomienia dewelopera i zarejestrowania szczegółów błędu w klasie kodu niestandardowej strony błędu? Chociaż z pewnością możesz dodać kod do niestandardowej klasy za pomocą kodu strony błędu, nie masz dostępu do szczegółów wyjątku, który wyzwolił Error zdarzenie podczas korzystania z techniki, którą omówiliśmy w poprzednim samouczku. GetLastError Wywołanie metody ze strony błędu niestandardowego zwraca wartość 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. GetLastError Dlatego zwraca wynik null wywołania z niestandardowej strony błędu.

Istnieje jednak możliwość wykonania niestandardowej strony błędu podczas 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. Kod programu Application_Error obsługi zdarzeń można przenieść do niestandardowej klasy za pomocą kodu strony błędu, zastępując go 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 uniemożliwia aparatowi ASP.NET przekierowywanie 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:

Poprzedni Następny

Udostępnij za pośrednictwem

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

Wprowadzenie

Wykonywanie kodu po wystąpieniu`Error`zdarzenia

Pobieranie informacji o nieobsługiwanym wyjątku

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

Co z używaniem niestandardowej strony błędu?

Podsumowanie

Dalsze informacje

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

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

Wprowadzenie

Wykonywanie kodu po wystąpieniuErrorzdarzenia

Pobieranie informacji o nieobsługiwanym wyjątku

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

Co z używaniem niestandardowej strony błędu?

Podsumowanie

Dalsze informacje

Opinia

Dodatkowe zasoby

Wykonywanie kodu po wystąpieniu`Error`zdarzenia