obsługa błędów ASP.NET

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

W tej serii samouczków przedstawiono podstawy tworzenia aplikacji ASP.NET Web Forms przy użyciu ASP.NET 4.5 i Microsoft Visual Studio Express 2013 for Web. Projekt programu Visual Studio 2013 z kodem źródłowym języka C# jest dostępny do dołączenia do 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ługiwanie błędów i wyświetlanie odpowiednio komunikatów o błędach. Rejestrowanie błędów umożliwia znajdowanie i naprawianie błędów, które wystąpiły. Ten samouczek bazuje na poprzednim przewodniku „Routing URL” i stanowi część serii przewodników Wingtip Toys.

Czego nauczysz się:

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

Przegląd

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

W programie .NET Framework wyjątek to obiekt, który dziedziczy z System.Exception klasy . Wyjątek jest zgłaszany z obszaru kodu, w którym wystąpił problem. Wyjątek jest przekazywany w górę stosu wywołań do miejsca, gdzie aplikacja zawiera 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/Catch/Finally 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ątków

Klasa Exception jest klasą bazową, z której dziedziczą wyjątki. Większość obiektów wyjątków to instancje klas pochodnych klasy Exception, takich jak SystemException, IndexOutOfRangeException czy ArgumentNullException. 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 wywodzących się z klasy SystemException, które są zgłaszane przez środowisko uruchomieniowe w przypadku napotkania wyjątku. Większość klas dziedziczynych z klasy Exception, takich jak IndexOutOfRangeException klasa i ArgumentNullException klasa, nie implementują dodatkowych składowych. W związku z tym 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 mogą być często pobierane i wyświetlane 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 dla 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 błędu, 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ń na poziomie strony

Program obsługi błędów na poziomie strony przekierowuje użytkownika z powrotem do strony, na której wystąpił błąd, ale ponieważ instancje kontrolek nie są zachowywane, na stronie nie będzie już niczego. 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 przekierowania użytkownika na stronę, która może wyświetlać przydatne informacje.

Przykład kodu pokazuje procedurę obsługi zdarzenia 'Error' na stronie 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 klasy), 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. Po wystąpieniu wyjątku środowisko uruchomieniowe języka wspólnego (CLR) wyszukuje instrukcję catch, która obsługuje ten wyjątek. Jeśli obecnie wykonywana metoda nie zawiera bloku catch, środowisko CLR analizuje metodę, która wywołała bieżącą metodę, i tak dalej, w górę stosu wywołań. Jeśli nie znaleziono bloku catch, 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/catch/finally funkcji 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 jego wykonania. Jeśli wystąpi wyjątek FileNotFoundException lub wyjątek IOException, wykonanie przenoszone jest na inną stronę. Następnie kod zawarty w bloku na koniec jest wykonywany, niezależnie od tego, czy wystąpił błąd.

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 . Dzięki temu za każdym razem, gdy aplikacja obsłuży błąd, szczegóły błędu zostaną dodane do pliku dziennika błędów.

Kliknij prawym przyciskiem myszy folder Logika , a następnie wybierz polecenie Dodaj ->Nowy element.
Zostanie wyświetlone okno dialogowe Dodawanie nowego elementu .
Wybierz grupę Szablony języka Visual C# ->Code po lewej stronie. Następnie wybierz pozycję Klasaz listy środkowej i nadaj jej nazwę ExceptionUtility.cs.
Wybierz opcję Dodaj. Zostanie wyświetlony nowy plik klasy.

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 tworzy żądanie HTTP obsługiwane lokalnie na maszynie, na której znajduje się kod, na stronie błędu zostaną wyświetlone dodatkowe szczegóły błędu.

Kliknij prawym przyciskiem myszy nazwę projektu (Wingtip Toys) w Eksploratorze rozwiązań i wybierz polecenie Dodaj ->Nowy element.
Zostanie wyświetlone okno dialogowe Dodawanie nowego elementu .
Wybierz po lewej stronie grupę szablonów Visual C# ->Web. Z środkowej listy wybierz pozycję Formularz internetowy ze stroną wzorcową i nadaj jej nazwę ErrorPage.aspx.
Kliknij przycisk Dodaj.
Wybierz plik Site.Master jako stronę wzorcową, a następnie wybierz przycisk OK.

Zastąp istniejący znacznik 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>

Zastąp istniejący kod w pliku code-behind (ErrorPage.aspx.cs) na 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;
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();
    }
  }
}

Po wyświetleniu strony błędu jest wykonywana Page_Load 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 maszyna lokalna z uruchomioną aplikacją internetową zobaczy 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żesz również określić sposób obsługi błędów na podstawie ich wartości kodu stanu, na przykład 404 — nie znaleziono pliku.

Aktualizowanie konfiguracji

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

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

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>

Zapisz plik Web.config.

Sekcja customErrors określa tryb, który jest ustawiony na "Włączone". Określa on 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 określający 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.

Naciśnij klawisz F5 , aby uruchomić przykładową aplikację Wingtip Toys.
Zostanie otwarta przeglądarka i zostanie wyświetlona strona Default.aspx .
Wprowadź następujący adres URL w przeglądarce (upewnij się, że używasz swojego numeru portu):
https://localhost:44300/NoPage.aspx
Przejrzyj stronę ErrorPage.aspx wyświetlaną w przeglądarce.

Gdy zażądasz 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ł nieistniejącej strony z lokalizacji zdalnej, strona błędu będzie wyświetlać 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.

Otwórz kod strony Default.aspx w programie Visual Studio.
Zostanie wyświetlona strona zaplecza kodu Default.aspx.cs.

W obsłudze Page_Load dodaj kod, aby procedura obsługi wyglądała następująco:

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 element InvalidOperationException po załadowaniu strony Default.aspx .

Uruchamianie aplikacji

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

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

Uwaga / Notatka

Naciśnij klawisze CTRL+F5 , aby wyświetlić stronę bez włamywania się do kodu, aby wyświetlić źródło błędu w programie Visual Studio.
Przejrzyj stronę ErrorPage.aspx, która jest wyświetlana w przeglądarce.

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 na poziomie aplikacji

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

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

Dodaj obsługę błędów Application_Error, aby działała 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 wywoływana jest Application_Error procedura obsługi. 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 przekierowuje wykonanie na stronę 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 wynikające z obsługi wyjątku na poziomie aplikacji.

Naciśnij klawisze CTRL+F5 , aby uruchomić przykładową aplikację Wingtip Toys.
Aplikacja zgłasza element InvalidOperationException .
Przejrzyj ErrorPage.aspx wyświetlane w przeglądarce.

Dodawanie obsługi błędów na poziomie stron

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 będzie przesyłać wykonywanie do strony ErrorPage.aspx .

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

Dodaj obsługę Page_Error, aby kod-behind 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, jest wywoływana Page_Error procedura obsługi zdarzeń. W tej procedurze obsługi ostatni wyjątek jest pobierany i przeglądany. Jeśli wystąpi InvalidOperationException, program obsługi zdarzeń Page_Error przekierowuje wykonanie do strony błędu, gdzie są wyświetlane szczegóły wyjątku.

Uruchamianie aplikacji

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

Naciśnij klawisze CTRL+F5 , aby uruchomić przykładową aplikację Wingtip Toys.
Aplikacja zgłasza element InvalidOperationException .
Przejrzyj ErrorPage.aspx wyświetlaną w przeglądarce.
Zamknij okno przeglądarki.

Usuwanie wyjątku używanego do testowania

Aby przykładowa aplikacja Wingtip Toys mogła działać bez zgłaszania wyjątku dodanego wcześniej w tym samouczku, usuń wyjątek.

Otwórz kod strony Default.aspx .
W procedurze obsługi Page_Load usuń kod, który zgłasza wyjątek, aby obsługa wyglądała następująco:
```
protected void Page_Load(object sender, EventArgs e)
{

}
```

Dodawanie rejestrowania błędów na poziomie kodu

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 szczegóły błędu zostaną zapisane tylko w pliku dziennika błędów, aby można było przejrzeć go później.

W Eksploratorze rozwiązań w folderze Logika znajdź i otwórz plik PayPalFunctions.cs .

Zaktualizuj metodę HttpCall tak, 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ę LogException, która jest zawarta w klasie ExceptionUtility. 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 rejestrowane będą tylko błędy, które zostały wychwycone i zapisane w dzienniku błędów.

W Eksploratorze 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 Eksploratora rozwiązań , aby wyświetlić plik ErrorLog.txt .
Przejrzyj dziennik błędów wyświetlany w programie Visual Studio:

Bezpieczne komunikaty o błędach

Należy pamiętać, że gdy aplikacja wyświetla komunikaty o błędach, nie powinna podawać informacji, które złośliwy użytkownik może znaleźć w ataku na aplikację. Jeśli na przykład aplikacja bezskutecznie 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 dla użytkownika jest wyświetlany ogólny komunikat o błędzie w kolorze czerwonym. Wszystkie dodatkowe szczegóły błędu są wyświetlane tylko deweloperowi na komputerze lokalnym.

Korzystanie z ELMAH

ELMAH (Moduły rejestrowania błędów i programy obsługi) to funkcjonalność rejestrowania błędów, którą można podłączyć do aplikacji ASP.NET jako pakiet NuGet. ELMAH zapewnia następujące możliwości:

Rejestrowanie nieobsługiwanych wyjątków.
Strona WWW do przeglądania całego dziennika nieobsłużonych wyjątków.
Strona internetowa zawierająca pełne szczegóły każdego zarejestrowanego wyjątku.
Powiadomienie e-mail o każdym błędzie w momencie jego wystąpienia.
Kanał RSS zawierający 15 ostatnich błędów z dziennika.

Przed rozpoczęciem pracy z elmAH należy go zainstalować. Jest to łatwe w 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 typu open source w programie Visual Studio.

W programie Visual Studio z menu Narzędzia wybierz pozycję Menedżer pakietów NuGet>, Zarządzaj pakietami NuGet dla rozwiązania.
Okno dialogowe Zarządzanie pakietami NuGet jest wyświetlane w programie Visual Studio.
W oknie dialogowym Zarządzanie pakietami NuGet rozwiń Online po lewej stronie, a następnie wybierz nuget.org. Następnie znajdź i zainstaluj pakiet ELMAH z listy dostępnych pakietów online.
Aby pobrać pakiet, musisz mieć połączenie internetowe.
W oknie dialogowym Wybieranie projektów upewnij się, że zaznaczono zaznaczenie opcji WingtipToys , a następnie kliknij przycisk OK.
W razie potrzeby kliknij przycisk Zamknij w oknie dialogowym Zarządzanie pakietami NuGet .
Jeśli program Visual Studio zażąda ponownego załadowania otwartych plików, wybierz pozycję "Tak do wszystkich".
Pakiet ELMAH dodaje swoje wpisy do pliku Web.config w katalogu głównym projektu. Jeśli program Visual Studio wyświetli pytanie, czy chcesz ponownie załadować zmodyfikowany plik Web.config , kliknij przycisk Tak.

Teraz ELMAH jest gotowy do przechowywania wszystkich 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.

Naciśnij klawisze CTRL+F5 , aby uruchomić przykładową aplikację Wingtip Toys.
Aby zapisać 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.
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

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 przeglądu. Dodałeś narzędzie ELMAH, aby zapewnić rejestrowanie wyjątków i powiadomienia dla aplikacji za pomocą NuGet. Ponadto przedstawiono znaczenie bezpiecznych komunikatów o błędach.

Podsumowanie z serii samouczków

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

Dzięki - Erik

Dalsze kroki

Dowiedz się więcej o wdrażaniu aplikacji internetowej na platformie Microsoft Azure, zobacz Wdrażanie bezpiecznej aplikacji ASP.NET Web Forms z członkostwem, OAuth i bazą danych SQL do witryny internetowej platformy Azure.

Bezpłatna wersja próbna

Microsoft Azure — bezpłatna wersja próbna
Publikowanie witryny internetowej na platformie Microsoft Azure pozwala zaoszczędzić czas, konserwację i wydatki. Jest to szybki proces wdrażania aplikacji internetowej na platformie Azure. Jeśli 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, obsługą komunikatów, multimediami i wydajnością na platformie Azure. I wszystko to jest dostępne w bardzo opłacalnym podejściu.

Dodatkowe zasoby

Rejestrowanie szczegółów błędu za pomocą monitorowania stanu 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:

Alberto Poblacion, MVP i MCT, Hiszpania
Alex Thissen, Holandia (twitter: @alexthissen)
Andre Tournier, USA
Apurva Joshi, Microsoft
Bojan Vrhovnik, Słowenia
Bruno Sonnino, Brazylia (twitter: @bsonnino)
Carlos dos Santos, Brazylia
Dave Campbell, USA (twitter: @windowsdevnews)
Jon Galloway, Microsoft (twitter: @jongalloway)
Michael Sharps, USA (twitter: @mrsharps)
Mike Pope
Mitchel Sellers, USA (twitter: @MitchelSellers)
Paul Cociuba, Microsoft
Paulo Morgado, Portugalia
Pranav Rastogi, Microsoft
Tim Ammann, Microsoft
Tom Dykstra, Microsoft

Wkład społeczności

Graham Mendick (@grahammendick)
Przykładowy kod powiązany z programem Visual Studio 2012 w witrynie MSDN: Navigation Wingtip Toys
James Chaney (jchaney@agvance.net)
Przykładowy kod powiązany z programem Visual Studio 2012 w witrynie MSDN: seria samouczków ASP.NET 4.5 Web Forms w visual basic
Andrielle Azevedo — współtwórca treści technicznych dla odbiorców firmy Microsoft (twitter: @driazevedo)
Tłumaczenie programu Visual Studio 2012: Iniciando com ASP.NET Web Forms 4.5 — Parte 1 — Introdução e Visão Geral

Poprzednie

Opinia

Czy ta strona była pomocna?

Last updated on 2026-03-28