Udostępnij za pośrednictwem

Obsługa błędów platformy ASP.NET

  • Artykuł

Autor: Erik Reitan

Pobierz przykładowy projekt Wingtip Toys (C#) lub pobierz książkę elektroniczną (PDF)

Ta seria samouczków zawiera podstawowe informacje dotyczące tworzenia aplikacji ASP.NET Web Forms przy użyciu ASP.NET 4.5 i Microsoft Visual Studio Express 2013 for Web. Dostępny jest projekt Visual Studio 2013 z kodem źródłowym języka C#, który towarzyszy tej serii samouczków.

W tym samouczku zmodyfikujesz przykładową aplikację Wingtip Toys, aby zawierała obsługę błędów i rejestrowanie błędów. Obsługa błędów umożliwi aplikacji bezproblemowe obsługę błędów i odpowiednie wyświetlanie komunikatów o błędach. Rejestrowanie błędów umożliwia znajdowanie i naprawianie błędów, które wystąpiły. Ten samouczek jest oparty na poprzednim samouczku "Routing adresu URL" i jest częścią serii samouczków Wingtip Toys.

Zawartość:

  • Jak dodać globalną obsługę błędów do konfiguracji aplikacji.
  • Jak dodać obsługę błędów na poziomie aplikacji, strony i kodu.
  • Jak rejestrować błędy do późniejszego przeglądu.
  • Jak wyświetlać komunikaty o błędach, które nie zagrażają bezpieczeństwu.
  • Jak zaimplementować moduły rejestrowania błędów i rejestrowanie błędów programów obsługi (ELMAH).

Omówienie

ASP.NET aplikacje muszą mieć możliwość obsługi błędów występujących podczas wykonywania w spójny sposób. ASP.NET używa środowiska uruchomieniowego języka wspólnego (CLR), które zapewnia sposób powiadamiania aplikacji o błędach w jednolity sposób. W przypadku wystąpienia błędu zgłaszany jest wyjątek. Wyjątek to dowolny błąd, warunek lub nieoczekiwane zachowanie napotykane przez aplikację.

W .NET Framework wyjątkiem jest obiekt, który dziedziczy po System.Exception klasie. Wyjątek jest zgłaszany z obszaru kodu, w którym wystąpił problem. Wyjątek jest przekazywany do stosu wywołań do miejsca, w którym aplikacja udostępnia kod do obsługi wyjątku. Jeśli aplikacja nie obsługuje wyjątku, przeglądarka zostanie zmuszona do wyświetlenia szczegółów błędu.

Najlepszym rozwiązaniem jest obsługa błędów na poziomie kodu w blokach w Try//CatchFinally kodzie. Spróbuj umieścić te bloki, aby użytkownik mógł rozwiązać problemy w kontekście, w którym występują. Jeśli bloki obsługi błędów są zbyt odległe od miejsca wystąpienia błędu, trudniej jest zapewnić użytkownikom informacje potrzebne do rozwiązania problemu.

Klasa wyjątku

Klasa Exception jest klasą bazową, z której dziedziczą wyjątki. Większość obiektów wyjątków to wystąpienia niektórych klas pochodnych klasy Exception, takich jak SystemException klasa, klasa, IndexOutOfRangeException klasa lub ArgumentNullException klasa. Klasa Exception ma właściwości, takie jak StackTrace właściwość, InnerException właściwość i Message właściwość, które zawierają określone informacje o błędzie, który wystąpił.

Hierarchia dziedziczenia wyjątków

Środowisko uruchomieniowe ma podstawowy zestaw wyjątków wynikających z SystemException klasy, którą zgłasza środowisko uruchomieniowe w przypadku wystąpienia wyjątku. Większość klas dziedziczy z klasy Exception, takich jak IndexOutOfRangeException klasa i ArgumentNullException klasa, nie implementują dodatkowych składowych. Dlatego najważniejsze informacje dotyczące wyjątku można znaleźć w hierarchii wyjątków, nazwie wyjątku i informacjach zawartych w wyjątku.

Hierarchia obsługi wyjątków

W aplikacji ASP.NET Web Forms wyjątki można obsługiwać w oparciu o określoną hierarchię obsługi. Wyjątek można obsłużyć na następujących poziomach:

  • Poziom aplikacji
  • Poziom strony
  • Poziom kodu

Gdy aplikacja obsługuje wyjątki, dodatkowe informacje o wyjątku dziedziczone z klasy Wyjątki można często pobierać i wyświetlać użytkownikowi. Oprócz poziomu aplikacji, strony i kodu można również obsługiwać wyjątki na poziomie modułu HTTP i przy użyciu niestandardowego programu obsługi usług IIS.

Obsługa błędów na poziomie aplikacji

Błędy domyślne można obsługiwać na poziomie aplikacji, modyfikując konfigurację aplikacji lub dodając procedurę Application_Error obsługi w pliku Global.asax aplikacji.

Błędy domyślne i błędy HTTP można obsługiwać, dodając sekcję customErrors do pliku Web.config . Sekcja customErrors umożliwia określenie domyślnej strony, do której użytkownicy będą przekierowywani po wystąpieniu błędu. Umożliwia również określenie poszczególnych stron pod kątem określonych błędów kodu stanu.

<configuration>
  <system.web>
    <customErrors mode="On" defaultRedirect="ErrorPage.aspx?handler=customErrors%20section%20-%20Web.config">
      <error statusCode="404" redirect="ErrorPage.aspx?msg=404&amp;handler=customErrors%20section%20-%20Web.config"/>
    </customErrors>
  </system.web>
</configuration>

Niestety, jeśli używasz konfiguracji do przekierowania użytkownika do innej strony, nie masz szczegółów o błędzie, który wystąpił.

Można jednak wychwytować błędy występujące w dowolnym miejscu w aplikacji, dodając kod do Application_Error programu obsługi w pliku Global.asax .

void Application_Error(object sender, EventArgs e)
{
    Exception exc = Server.GetLastError();

    if (exc is HttpUnhandledException)
    {
        // Pass the error on to the error page.
        Server.Transfer("ErrorPage.aspx?handler=Application_Error%20-%20Global.asax", true);
    }
}

Obsługa zdarzeń błędów na poziomie strony

Procedura obsługi na poziomie strony zwraca użytkownika do strony, na której wystąpił błąd, ale ponieważ wystąpienia kontrolek nie są zachowywane, na stronie nie będzie już nic. Aby podać szczegóły błędu użytkownikowi aplikacji, musisz w szczególności zapisać szczegóły błędu na stronie.

Zazwyczaj program obsługi błędów na poziomie strony służy do rejestrowania nieobsługiwanych błędów lub do wyświetlenia przydatnych informacji przez użytkownika.

W tym przykładzie kodu przedstawiono procedurę obsługi zdarzenia Błąd na stronie internetowej ASP.NET. Ta procedura obsługi przechwytuje wszystkie wyjątki, które nie są jeszcze obsługiwane w try/catch blokach na stronie.

private void Page_Error(object sender, EventArgs e)
{
    Exception exc = Server.GetLastError();

    // Handle specific exception.
    if (exc is HttpUnhandledException)
    {
        ErrorMsgTextBox.Text = "An error occurred on this page. Please verify your " +                  
        "information to resolve the issue."
    }
    // Clear the error from the server.
    Server.ClearError();
}

Po obsłużeniu błędu należy go wyczyścić, wywołując ClearError metodę obiektu Serwera (HttpServerUtility klasa), w przeciwnym razie zostanie wyświetlony błąd, który wystąpił wcześniej.

Obsługa błędów na poziomie kodu

Instrukcja try-catch składa się z bloku try, po którym następuje co najmniej jedna klauzula catch, która określa procedury obsługi dla różnych wyjątków. Gdy zgłaszany jest wyjątek, środowisko uruchomieniowe języka wspólnego (CLR) wyszukuje instrukcję catch, która obsługuje ten wyjątek. Jeśli obecnie wykonująca metoda nie zawiera bloku catch, CLR analizuje metodę, która nazwała bieżącą metodę itd., w górę stos wywołań. Jeśli blok catch nie zostanie znaleziony, clR wyświetla użytkownikowi komunikat o nieobsługiwanym wyjątku i zatrzymuje wykonywanie programu.

Poniższy przykład kodu przedstawia typowy sposób użycia try//catchfinally metody do obsługi błędów.

try
{
    file.ReadBlock(buffer, index, buffer.Length);
}
catch (FileNotFoundException e)
{
    Server.Transfer("NoFileErrorPage.aspx", true);
}
catch (System.IO.IOException e)
{
    Server.Transfer("IOErrorPage.aspx", true);
}

finally
{
    if (file != null)
    {
        file.Close();
    }
}

W powyższym kodzie blok try zawiera kod, który musi być chroniony przed możliwym wyjątkiem. Blok jest wykonywany do momentu zgłoszenia wyjątku lub pomyślnego zakończenia bloku. FileNotFoundException Jeśli wystąpi wyjątek lub IOException wyjątek, wykonanie jest przenoszone na inną stronę. Następnie kod zawarty w bloku finally jest wykonywany, niezależnie od tego, czy wystąpił błąd, czy też nie.

Dodawanie obsługi rejestrowania błędów

Przed dodaniem obsługi błędów do przykładowej aplikacji Wingtip Toys dodasz obsługę rejestrowania błędów, dodając klasę ExceptionUtility do folderu logiki . W ten sposób za każdym razem, gdy aplikacja obsłuży błąd, szczegóły błędu zostaną dodane do pliku dziennika błędów.

  1. Kliknij prawym przyciskiem myszy folder Logika , a następnie wybierz polecenie Dodaj ->Nowy element.
    Zostanie wyświetlone okno dialogowe Dodaj nowy element.

  2. Wybierz grupę Szablony visual C# ->Code po lewej stronie. Następnie wybierz pozycję Klasaz listy środkowej i nadaj jej nazwę ExceptionUtility.cs.

  3. Wybierz pozycję Dodaj. Zostanie wyświetlony nowy plik klasy.

  4. Zastąp istniejący kod następującym kodem:

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.IO;

namespace WingtipToys.Logic
{
  // Create our own utility for exceptions
  public sealed class ExceptionUtility
  {
    // All methods are static, so this can be private
    private ExceptionUtility()
    { }

    // Log an Exception
    public static void LogException(Exception exc, string source)
    {
      // Include logic for logging exceptions
      // Get the absolute path to the log file
      string logFile = "~/App_Data/ErrorLog.txt";
      logFile = HttpContext.Current.Server.MapPath(logFile);

      // Open the log file for append and write the log
      StreamWriter sw = new StreamWriter(logFile, true);
      sw.WriteLine("********** {0} **********", DateTime.Now);
      if (exc.InnerException != null)
      {
        sw.Write("Inner Exception Type: ");
        sw.WriteLine(exc.InnerException.GetType().ToString());
        sw.Write("Inner Exception: ");
        sw.WriteLine(exc.InnerException.Message);
        sw.Write("Inner Source: ");
        sw.WriteLine(exc.InnerException.Source);
        if (exc.InnerException.StackTrace != null)
        {
          sw.WriteLine("Inner Stack Trace: ");
          sw.WriteLine(exc.InnerException.StackTrace);
        }
      }
      sw.Write("Exception Type: ");
      sw.WriteLine(exc.GetType().ToString());
      sw.WriteLine("Exception: " + exc.Message);
      sw.WriteLine("Source: " + source);
      sw.WriteLine("Stack Trace: ");
      if (exc.StackTrace != null)
      {
        sw.WriteLine(exc.StackTrace);
        sw.WriteLine();
      }
      sw.Close();
    }
  }
}

W przypadku wystąpienia wyjątku wyjątek można zapisać w pliku dziennika wyjątków, wywołując metodę LogException . Ta metoda przyjmuje dwa parametry, obiekt wyjątku i ciąg zawierający szczegółowe informacje o źródle wyjątku. Dziennik wyjątków jest zapisywany w pliku ErrorLog.txt w folderze App_Data .

Dodawanie strony błędu

W przykładowej aplikacji Wingtip Toys jedna strona będzie używana do wyświetlania błędów. Strona błędu została zaprojektowana w celu wyświetlenia bezpiecznego komunikatu o błędzie dla użytkowników witryny. Jeśli jednak użytkownik jest deweloperem wysyłającym żądanie HTTP, które jest obsługiwane lokalnie na maszynie, na której znajduje się kod, dodatkowe szczegóły błędu będą wyświetlane na stronie błędu.

  1. Kliknij prawym przyciskiem myszy nazwę projektu (Wingtip Toys) w Eksplorator rozwiązań i wybierz polecenie Dodaj ->Nowy element.
    Zostanie wyświetlone okno dialogowe Dodaj nowy element.

  2. Wybierz grupę Visual C# ->Web templates po lewej stronie. Z środkowej listy wybierz pozycję Formularz internetowy ze stroną wzorcową i nadaj jej nazwę ErrorPage.aspx.

  3. Kliknij pozycję Dodaj.

  4. Wybierz plik Site.Master jako stronę wzorcową, a następnie wybierz przycisk OK.

  5. Zastąp istniejącą adiustację następującym kodem:

    <%@ Page Title="" Language="C#" AutoEventWireup="true" MasterPageFile="~/Site.Master"  CodeBehind="ErrorPage.aspx.cs" Inherits="WingtipToys.ErrorPage" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" runat="server">
    <h2>Error:</h2>
    <p></p>
    <asp:Label ID="FriendlyErrorMsg" runat="server" Text="Label" Font-Size="Large" style="color: red"></asp:Label>

    <asp:Panel ID="DetailedErrorPanel" runat="server" Visible="false">
        <p>&nbsp;</p>
        <h4>Detailed Error:</h4>
        <p>
            <asp:Label ID="ErrorDetailedMsg" runat="server" Font-Size="Small" /><br />
        </p>

        <h4>Error Handler:</h4>
        <p>
            <asp:Label ID="ErrorHandler" runat="server" Font-Size="Small" /><br />
        </p>

        <h4>Detailed Error Message:</h4>
        <p>
            <asp:Label ID="InnerMessage" runat="server" Font-Size="Small" /><br />
        </p>
        <p>
            <asp:Label ID="InnerTrace" runat="server"  />
        </p>
    </asp:Panel>
</asp:Content>

  6. Zastąp istniejący kod pliku code-behind (ErrorPage.aspx.cs), aby wyglądał następująco:

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using WingtipToys.Logic;

namespace WingtipToys
{
  public partial class ErrorPage : System.Web.UI.Page
  {
    protected void Page_Load(object sender, EventArgs e)
    {
      // Create safe error messages.
      string generalErrorMsg = "A problem has occurred on this web site. Please try again. " +
          "If this error continues, please contact support.";
      string httpErrorMsg = "An HTTP error occurred. Page Not found. Please try again.";
      string unhandledErrorMsg = "The error was unhandled by application code.";

      // Display safe error message.
      FriendlyErrorMsg.Text = generalErrorMsg;

      // Determine where error was handled.
      string errorHandler = Request.QueryString["handler"];
      if (errorHandler == null)
      {
        errorHandler = "Error Page";
      }

      // Get the last error from the server.
      Exception ex = Server.GetLastError();

      // Get the error number passed as a querystring value.
      string errorMsg = Request.QueryString["msg"];
      if (errorMsg == "404")
      {
        ex = new HttpException(404, httpErrorMsg, ex);
        FriendlyErrorMsg.Text = ex.Message;
      }

      // If the exception no longer exists, create a generic exception.
      if (ex == null)
      {
        ex = new Exception(unhandledErrorMsg);
      }

      // Show error details to only you (developer). LOCAL ACCESS ONLY.
      if (Request.IsLocal)
      {
        // Detailed Error Message.
        ErrorDetailedMsg.Text = ex.Message;

        // Show where the error was handled.
        ErrorHandler.Text = errorHandler;

        // Show local access details.
        DetailedErrorPanel.Visible = true;

        if (ex.InnerException != null)
        {
          InnerMessage.Text = ex.GetType().ToString() + "<br/>" +
              ex.InnerException.Message;
          InnerTrace.Text = ex.InnerException.StackTrace;
        }
        else
        {
          InnerMessage.Text = ex.GetType().ToString();
          if (ex.StackTrace != null)
          {
            InnerTrace.Text = ex.StackTrace.ToString().TrimStart();
          }
        }
      }

      // Log the exception.
      ExceptionUtility.LogException(ex, errorHandler);

      // Clear the error from the server.
      Server.ClearError();
    }
  }
}

Gdy zostanie wyświetlona strona błędu, Page_Load zostanie wykonana procedura obsługi zdarzeń. W procedurze Page_Load obsługi określana jest lokalizacja, w której najpierw obsłużono błąd. Następnie ostatni błąd, który wystąpił, jest określany przez wywołanie GetLastError metody obiektu Server. Jeśli wyjątek już nie istnieje, zostanie utworzony wyjątek ogólny. Następnie, jeśli żądanie HTTP zostało wykonane lokalnie, zostaną wyświetlone wszystkie szczegóły błędu. W takim przypadku tylko komputer lokalny z uruchomioną aplikacją internetową będzie widzieć te szczegóły błędu. Po wyświetleniu informacji o błędzie błąd zostanie dodany do pliku dziennika, a błąd zostanie wyczyszczone z serwera.

Wyświetlanie nieobsługiwanych komunikatów o błędach dla aplikacji

Dodając sekcję customErrors do pliku Web.config , można szybko obsługiwać proste błędy występujące w całej aplikacji. Można również określić sposób obsługi błędów na podstawie ich wartości kodu stanu, takiej jak 404 — nie można odnaleźć pliku.

Aktualizowanie konfiguracji

Zaktualizuj konfigurację, dodając sekcję customErrors do pliku Web.config .

  1. W Eksplorator rozwiązań znajdź i otwórz plik Web.config w katalogu głównym przykładowej aplikacji Wingtip Toys.

  2. Dodaj sekcję customErrors do pliku Web.config w węźle <system.web> w następujący sposób:

    <configuration>
  <system.web>
    <customErrors mode="On" defaultRedirect="ErrorPage.aspx?handler=customErrors%20section%20-%20Web.config">
      <error statusCode="404" redirect="ErrorPage.aspx?msg=404&amp;handler=customErrors%20section%20-%20Web.config"/>
    </customErrors>
  </system.web>
</configuration>

  3. Zapisz plik Web.config .

Sekcja customErrors określa tryb, który jest ustawiony na "Włączone". Określa również element , który informuje aplikację defaultRedirect, do której strony ma przejść po wystąpieniu błędu. Ponadto dodano określony element błędu, który określa sposób obsługi błędu 404, gdy strona nie zostanie znaleziona. W dalszej części tego samouczka dodasz dodatkową obsługę błędów, która przechwytuje szczegóły błędu na poziomie aplikacji.

Uruchamianie aplikacji

Teraz możesz uruchomić aplikację, aby wyświetlić zaktualizowane trasy.

  1. Naciśnij klawisz F5 , aby uruchomić przykładową aplikację Wingtip Toys.
    Zostanie otwarta przeglądarka i zostanie wyświetlona strona Default.aspx .

  2. Wprowadź następujący adres URL w przeglądarce (pamiętaj, aby użyć numeru portu):
    https://localhost:44300/NoPage.aspx

  3. Przejrzyj plik ErrorPage.aspx wyświetlany w przeglądarce.

    obsługa błędów ASP.NET — błąd nie znaleziono strony

Po zażądaniu strony NoPage.aspx , która nie istnieje, na stronie błędu zostanie wyświetlony prosty komunikat o błędzie i szczegółowe informacje o błędzie, jeśli są dostępne dodatkowe szczegóły. Jeśli jednak użytkownik zażądał strony nieistniejącej z lokalizacji zdalnej, na stronie błędu będzie wyświetlany tylko komunikat o błędzie na czerwono.

Dołączanie wyjątku do celów testowych

Aby sprawdzić, jak aplikacja będzie działać po wystąpieniu błędu, możesz celowo utworzyć warunki błędu w ASP.NET. W przykładowej aplikacji Wingtip Toys zgłosisz wyjątek testowy, gdy domyślna strona zostanie załadowana, aby zobaczyć, co się stanie.

  1. Otwórz stronę Default.aspx w programie Visual Studio.
    Zostanie wyświetlona strona Default.aspx.cs z tyłu kodu.

  2. W procedurze Page_Load obsługi dodaj kod, aby program obsługi był wyświetlany w następujący sposób:

    protected void Page_Load(object sender, EventArgs e)
{
    throw new InvalidOperationException("An InvalidOperationException " +
    "occurred in the Page_Load handler on the Default.aspx page.");
}

Istnieje możliwość utworzenia różnych typów wyjątków. W powyższym kodzie tworzysz InvalidOperationException stronę Default.aspx .

Uruchamianie aplikacji

Możesz uruchomić aplikację, aby zobaczyć, jak aplikacja obsługuje wyjątek.

  1. Naciśnij klawisze CTRL+F5 , aby uruchomić przykładową aplikację Wingtip Toys.
    Aplikacja zgłasza wyjątek InvalidOperationException.

    Uwaga

    Musisz nacisnąć klawisze CTRL+F5 , aby wyświetlić stronę bez podziału na kod, aby wyświetlić źródło błędu w programie Visual Studio.

  2. Przejrzyj plik ErrorPage.aspx wyświetlany w przeglądarce.

    obsługa błędów ASP.NET — strona błędu

Jak widać w szczegółach błędu, wyjątek został uwięziony przez sekcję customError w pliku Web.config .

Dodawanie obsługi błędów Application-Level

Zamiast pułapki wyjątku customErrors przy użyciu sekcji w pliku Web.config , gdzie uzyskasz niewiele informacji o wyjątku, możesz wychwytować błąd na poziomie aplikacji i pobrać szczegóły błędu.

  1. W Eksplorator rozwiązań znajdź i otwórz plik Global.asax.cs.

  2. Dodaj procedurę obsługi Application_Error , aby była wyświetlana w następujący sposób:

    void Application_Error(object sender, EventArgs e)
{
  // Code that runs when an unhandled error occurs.

  // Get last error from the server
  Exception exc = Server.GetLastError();

  if (exc is HttpUnhandledException)
  {
    if (exc.InnerException != null)
    {
      exc = new Exception(exc.InnerException.Message);
      Server.Transfer("ErrorPage.aspx?handler=Application_Error%20-%20Global.asax",
          true);
    }
  }
}

W przypadku wystąpienia błędu w aplikacji program obsługi jest wywoływany Application_Error . W tej procedurze obsługi ostatni wyjątek jest pobierany i przeglądany. Jeśli wyjątek był nieobsługiwany, a wyjątek zawiera szczegóły wyjątku wewnętrznego (czyli InnerException nie ma wartości null), aplikacja przenosi wykonywanie do strony błędu, na której są wyświetlane szczegóły wyjątku.

Uruchamianie aplikacji

Możesz uruchomić aplikację, aby wyświetlić dodatkowe szczegóły błędu podane przez obsługę wyjątku na poziomie aplikacji.

  1. Naciśnij klawisze CTRL+F5 , aby uruchomić przykładową aplikację Wingtip Toys.
    Aplikacja zgłasza element InvalidOperationException .

  2. Przejrzyj plik ErrorPage.aspx wyświetlany w przeglądarce.

    obsługa błędów ASP.NET — błąd na poziomie aplikacji

Dodawanie obsługi błędów Page-Level

Obsługę błędów na poziomie strony można dodać do strony, dodając ErrorPage atrybut do @Page dyrektywy strony lub dodając Page_Error procedurę obsługi zdarzeń do kodu strony. W tej sekcji dodasz procedurę Page_Error obsługi zdarzeń, która przeniesie wykonanie do strony ErrorPage.aspx .

  1. W Eksplorator rozwiązań znajdź i otwórz plik Default.aspx.cs.

  2. Dodaj procedurę Page_Error obsługi, aby kod był wyświetlany w następujący sposób:

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WingtipToys
{
  public partial class _Default : Page
  {
    protected void Page_Load(object sender, EventArgs e)
    {
      throw new InvalidOperationException("An InvalidOperationException " +
      "occurred in the Page_Load handler on the Default.aspx page.");
    }

    private void Page_Error(object sender, EventArgs e)
    {
      // Get last error from the server.
      Exception exc = Server.GetLastError();

      // Handle specific exception.
      if (exc is InvalidOperationException)
      {
        // Pass the error on to the error page.
        Server.Transfer("ErrorPage.aspx?handler=Page_Error%20-%20Default.aspx",
            true);
      }
    }
  }
}

Po wystąpieniu błędu na stronie wywoływana Page_Error jest procedura obsługi zdarzeń. W tej procedurze obsługi ostatni wyjątek jest pobierany i przeglądany. W takim przypadku InvalidOperationExceptionPage_Error program obsługi zdarzeń przenosi wykonywanie na stronę błędu, na której są wyświetlane szczegóły wyjątku.

Uruchamianie aplikacji

Teraz możesz uruchomić aplikację, aby wyświetlić zaktualizowane trasy.

  1. Naciśnij klawisze CTRL+F5 , aby uruchomić przykładową aplikację Wingtip Toys.
    Aplikacja zgłasza element InvalidOperationException .

  2. Przejrzyj plik ErrorPage.aspx wyświetlany w przeglądarce.

    obsługa błędów ASP.NET — błąd na poziomie strony

  3. Zamknij okno przeglądarki.

Usuwanie wyjątku używanego do testowania

Aby zezwolić przykładowej aplikacji Wingtip Toys na działanie bez zgłaszania wyjątku dodanego wcześniej w tym samouczku, usuń wyjątek.

  1. Otwórz kod strony Default.aspx .

  2. W procedurze Page_Load obsługi usuń kod, który zgłasza wyjątek, tak aby program obsługi był wyświetlany w następujący sposób:

    protected void Page_Load(object sender, EventArgs e)
{

}

Dodawanie rejestrowania błędów Code-Level

Jak wspomniano wcześniej w tym samouczku, możesz dodać instrukcje try/catch, aby spróbować uruchomić sekcję kodu i obsłużyć pierwszy błąd, który występuje. W tym przykładzie zapiszesz tylko szczegóły błędu w pliku dziennika błędów, aby można było je przejrzeć później.

  1. W Eksplorator rozwiązań w folderze Logic znajdź i otwórz plik PayPalFunctions.cs.

  2. Zaktualizuj metodę tak HttpCall , aby kod był wyświetlany w następujący sposób:

    public string HttpCall(string NvpRequest)
{
  string url = pEndPointURL;

  string strPost = NvpRequest + "&" + buildCredentialsNVPString();
  strPost = strPost + "&BUTTONSOURCE=" + HttpUtility.UrlEncode(BNCode);

  HttpWebRequest objRequest = (HttpWebRequest)WebRequest.Create(url);
  objRequest.Timeout = Timeout;
  objRequest.Method = "POST";
  objRequest.ContentLength = strPost.Length;

  try
  {
    using (StreamWriter myWriter = new StreamWriter(objRequest.GetRequestStream()))
    {
      myWriter.Write(strPost);
    }
  }
  catch (Exception e)
  {
    // Log the exception.
    WingtipToys.Logic.ExceptionUtility.LogException(e, "HttpCall in PayPalFunction.cs");
  }

  //Retrieve the Response returned from the NVP API call to PayPal.
  HttpWebResponse objResponse = (HttpWebResponse)objRequest.GetResponse();
  string result;
  using (StreamReader sr = new StreamReader(objResponse.GetResponseStream()))
  {
    result = sr.ReadToEnd();
  }

  return result;
}

Powyższy kod wywołuje metodę zawartą LogException w ExceptionUtility klasie . Wcześniej w tym samouczku dodano plik klasy ExceptionUtility.cs do folderu logiki . Metoda LogException przyjmuje dwa parametry. Pierwszy parametr jest obiektem wyjątku. Drugi parametr jest ciągiem używanym do rozpoznawania źródła błędu.

Sprawdzanie informacji o rejestrowaniu błędów

Jak wspomniano wcześniej, możesz użyć dziennika błędów, aby określić, które błędy w aplikacji powinny zostać naprawione jako pierwsze. Oczywiście zostaną zarejestrowane tylko błędy, które zostały uwięzione i zapisane w dzienniku błędów.

  1. W Eksplorator rozwiązań znajdź i otwórz plik ErrorLog.txt w folderze App_Data.
    Może być konieczne wybranie opcji "Pokaż wszystkie pliki" lub opcję "Odśwież" w górnej części Eksplorator rozwiązań, aby wyświetlić plik ErrorLog.txt.

  2. Przejrzyj dziennik błędów wyświetlany w programie Visual Studio:

    obsługa błędów ASP.NET — ErrorLog.txt

Bezpieczne komunikaty o błędach

Należy pamiętać, że gdy aplikacja wyświetla komunikaty o błędach, nie powinna ona udzielać informacji, które złośliwy użytkownik może znaleźć w ataku na aplikację. Jeśli na przykład aplikacja nieskutecznie próbuje zapisać w bazie danych, nie powinna wyświetlać komunikatu o błędzie zawierającego nazwę użytkownika, którego używa. Z tego powodu ogólny komunikat o błędzie w kolorze czerwonym jest wyświetlany użytkownikowi. Wszystkie dodatkowe szczegóły błędu są wyświetlane tylko dla dewelopera na komputerze lokalnym.

Korzystanie z ELMAH

ELMAH (moduły rejestrowania błędów i programy obsługi) to funkcja rejestrowania błędów podłączona do aplikacji ASP.NET jako pakiet NuGet. ElMAH zapewnia następujące możliwości:

  • Rejestrowanie nieobsługiwanych wyjątków.
  • Strona internetowa do wyświetlenia całego dziennika ponownie zakodowanych wyjątków.
  • Strona internetowa do wyświetlania pełnych szczegółów każdego zarejestrowanego wyjątku.
  • Powiadomienie e-mail o każdym błędzie w momencie jego wystąpienia.
  • Kanał informacyjny RSS z ostatnich 15 błędów z dziennika.

Przed rozpoczęciem pracy z ELMAH należy go zainstalować. Jest to łatwe przy użyciu instalatora pakietu NuGet . Jak wspomniano wcześniej w tej serii samouczków, NuGet to rozszerzenie programu Visual Studio, które ułatwia instalowanie i aktualizowanie bibliotek i narzędzi open source w programie Visual Studio.

  1. W programie Visual Studio z menu Narzędzia wybierz pozycję Menedżer> pakietówNuGet Zarządzaj pakietami NuGet dla rozwiązania.

    obsługa błędów ASP.NET — zarządzanie pakietami NuGet dla rozwiązania

  2. Okno dialogowe Zarządzanie pakietami NuGet jest wyświetlane w programie Visual Studio.

  3. W oknie dialogowym Zarządzanie pakietami NuGet rozwiń węzeł Online po lewej stronie, a następnie wybierz pozycję nuget.org. Następnie znajdź i zainstaluj pakiet ELMAH z listy dostępnych pakietów online.

    obsługa błędów ASP.NET — pakiet NuGet ELMA

  4. Aby pobrać pakiet, musisz mieć połączenie internetowe.

  5. W oknie dialogowym Wybieranie projektów upewnij się, że zaznaczono zaznaczenie opcji WingtipToys , a następnie kliknij przycisk OK.

    obsługa błędów ASP.NET — okno dialogowe Wybieranie projektów

  6. W razie potrzeby kliknij przycisk Zamknij w oknie dialogowym Zarządzanie pakietami NuGet .

  7. Jeśli program Visual Studio zażąda ponownego załadowania otwartych plików, wybierz pozycję "Tak do wszystkich".

  8. Pakiet ELMAH dodaje wpisy dla siebie w pliku Web.config w katalogu głównym projektu. Jeśli program Visual Studio pyta, czy chcesz ponownie załadować zmodyfikowany plik Web.config , kliknij przycisk Tak.

ElMAH jest teraz gotowy do przechowywania wszelkich nieobsługiwanych błędów, które występują.

Wyświetlanie dziennika ELMAH

Wyświetlanie dziennika ELMAH jest łatwe, ale najpierw utworzysz nieobsługiwany wyjątek, który zostanie zarejestrowany w dzienniku ELMAH.

  1. Naciśnij klawisze CTRL+F5 , aby uruchomić przykładową aplikację Wingtip Toys.

  2. Aby napisać nieobsługiwany wyjątek do dziennika ELMAH, przejdź w przeglądarce do następującego adresu URL (przy użyciu numeru portu):
    https://localhost:44300/NoPage.aspx Zostanie wyświetlona strona błędu.

  3. Aby wyświetlić dziennik ELMAH, przejdź w przeglądarce do następującego adresu URL (przy użyciu numeru portu):
    https://localhost:44300/elmah.axd

    obsługa błędów ASP.NET — dziennik błędów ELMAH

Podsumowanie

W tym samouczku przedstawiono obsługę błędów na poziomie aplikacji, na poziomie strony i na poziomie kodu. Wiesz również, jak rejestrować obsługiwane i nieobsługiwane błędy w celu późniejszego przejrzenia. Dodano narzędzie ELMAH w celu zapewnienia rejestrowania wyjątków i powiadomień do aplikacji przy użyciu narzędzia NuGet. Ponadto przedstawiono znaczenie bezpiecznych komunikatów o błędach.

Podsumowanie serii samouczków

Dziękujemy za obserwowanie. Mam nadzieję, że ten zestaw samouczków pomógł Ci lepiej zapoznać się z ASP.NET Web Forms. Jeśli potrzebujesz więcej informacji na temat funkcji Web Forms dostępnych w ASP.NET 4.5 i Visual Studio 2013, zobacz ASP.NET and Web Tools informacje o wersji Visual Studio 2013. Ponadto zapoznaj się z samouczkiem wymienionym w sekcji Następne kroki i wypróbuj bezpłatną wersję próbną platformy Azure.

Dzięki - Erik

Następne kroki

Dowiedz się więcej na temat wdrażania aplikacji internetowej na platformie Microsoft Azure, zobacz Deploy a Secure ASP.NET Web Forms App with Membership, OAuth and SQL Database to an Azure Web Site (Wdrażanie bezpiecznej aplikacji ASP.NET Web Forms przy użyciu członkostwa, uwierzytelniania OAuth i SQL Database w witrynie internetowej platformy Azure).

Bezpłatna wersja próbna

Microsoft Azure — bezpłatna wersja próbna
Publikowanie witryny internetowej na platformie Microsoft Azure pozwoli zaoszczędzić czas, konserwację i wydatki. Jest to szybki proces wdrażania aplikacji internetowej na platformie Azure. Gdy musisz obsługiwać i monitorować aplikację internetową, platforma Azure oferuje różne narzędzia i usługi. Zarządzanie danymi, ruchem, tożsamością, kopiami zapasowymi, wiadomościami, multimediami i wydajnością na platformie Azure. I wszystko to jest zapewniane w bardzo opłacalnym podejściu.

Dodatkowe zasoby

Rejestrowanie szczegółów błędu za pomocą monitorowania kondycji ASP.NET
ELMAH

Podziękowania

Chciałbym podziękować następującym osobom, które wniosły znaczący wkład w zawartość tej serii samouczków:

Współtworzenie w ramach społeczności

Poprzednie