ASP.NET Fehlerbehandlung

Wingtip Toys Sample Project (C#) herunterladen oder E-Book herunterladen (PDF)

In dieser Lernprogrammreihe lernen Sie die Grundlagen der Erstellung einer ASP.NET Web Forms-Anwendung mithilfe von ASP.NET 4.5 und Microsoft Visual Studio Express 2013 für Web kennen. Für diese Lernprogrammreihe steht ein Visual Studio 2013-Projekt mit C#-Quellcode zur Verfügung.

In diesem Lernprogramm ändern Sie die Wingtip Toys-Beispielanwendung so, dass sie Fehlerbehandlung und Fehlerprotokollierung enthält. Die Fehlerbehandlung ermöglicht es der Anwendung, Fehler ordnungsgemäß zu behandeln und Fehlermeldungen entsprechend anzuzeigen. Mit der Fehlerprotokollierung können Sie fehler finden und beheben, die aufgetreten sind. Dieses Lernprogramm baut auf dem vorherigen Lernprogramm "URL Routing" auf und ist Teil der Wingtip Toys-Lernreihe.

Was Sie lernen:

So fügen Sie der Konfiguration der Anwendung die globale Fehlerbehandlung hinzu.
So fügen Sie die Fehlerbehandlung auf Anwendungs-, Seiten- und Codeebene hinzu.
So protokollieren Sie Fehler für eine spätere Überprüfung.
So zeigen Sie Fehlermeldungen an, die keine Sicherheit gefährden.
Wie implementiert man Fehlerprotokollierungsmodule und -Handler (ELMAH)?

Übersicht

ASP.NET Anwendungen müssen Fehler behandeln können, die während der Ausführung auf konsistente Weise auftreten. ASP.NET verwendet die Common Language Runtime (CLR), die eine Möglichkeit bietet, Anwendungen auf einheitliche Weise über Fehler zu benachrichtigen. Wenn ein Fehler auftritt, wird eine Ausnahme ausgelöst. Eine Ausnahme ist ein Fehler, ein Zustand oder ein unerwartetes Verhalten, auf das eine Anwendung trifft.

In .NET Framework ist eine Ausnahme ein Objekt, das von der System.Exception Klasse erbt. Eine Ausnahme wird aus einem Codebereich ausgelöst, in dem ein Problem aufgetreten ist. Die Ausnahme wird an eine Stelle übergeben, an der die Anwendung Code zum Behandeln der Ausnahme bereitstellt. Wenn die Anwendung die Ausnahme nicht behandelt, wird der Browser gezwungen, die Fehlerdetails anzuzeigen.

Behandeln Sie als bewährte Methode Fehler auf Codeebene in Try/Catch/Finally Blöcken innerhalb des Codes. Versuchen Sie, diese Blöcke so zu platzieren, dass der Benutzer Probleme im Kontext beheben kann, in dem sie auftreten. Wenn die Fehlerbehandlungsblöcke zu weit davon entfernt sind, wo der Fehler aufgetreten ist, wird es schwieriger, Benutzern die Informationen bereitzustellen, die sie zum Beheben des Problems benötigen.

Exception-Klasse

Die Exception-Klasse ist die Basisklasse, von der Ausnahmen erben. Die meisten Ausnahmeobjekte sind Instanzen einer abgeleiteten Klasse der Exception-Klasse, z. B. die SystemException Klasse, die IndexOutOfRangeException Klasse oder die ArgumentNullException Klasse. Die Exception-Klasse verfügt über Eigenschaften, z. B. die StackTrace Eigenschaft, die InnerException Eigenschaft und die Message Eigenschaft, die spezifische Informationen zum aufgetretenen Fehler bereitstellt.

Ausnahmevererbungshierarchie

Die Laufzeit verfügt über einen Basissatz von Ausnahmen, die von der SystemException-Klasse abgeleitet sind, die die Laufzeit auslöst, wenn eine Ausnahme auftritt. Die meisten Klassen, die von der Exception-Klasse erben, z. B. die IndexOutOfRangeException Klasse und die ArgumentNullException Klasse, implementieren keine zusätzlichen Member. Daher können die wichtigsten Informationen für eine Ausnahme in der Hierarchie der Ausnahmen, des Ausnahmenamens und der in der Ausnahme enthaltenen Informationen gefunden werden.

Ausnahmebehandlungshierarchie

In einer ASP.NET Web Forms-Anwendung können Ausnahmen basierend auf einer bestimmten Behandlungshierarchie behandelt werden. Eine Ausnahme kann auf den folgenden Ebenen behandelt werden:

Anwendungsebene
Seitenebene
Codeebene

Wenn eine Anwendung Ausnahmen behandelt, können häufig zusätzliche Informationen zu der Ausnahme, die von der Exception-Klasse geerbt wird, abgerufen und dem Benutzer angezeigt werden. Zusätzlich zu Anwendung, Seite und Codeebene können Sie auch Ausnahmen auf HTTP-Modulebene und mithilfe eines benutzerdefinierten IIS-Handlers behandeln.

Fehlerbehandlung auf Anwendungsebene

Sie können Standardfehler auf Anwendungsebene behandeln, indem Sie entweder die Konfiguration Ihrer Anwendung ändern oder einen Application_Error Handler in der Datei "Global.asax " Ihrer Anwendung hinzufügen.

Sie können Standardfehler und HTTP-Fehler behandeln, indem Sie der customErrors Datei einen Abschnitt hinzufügen. Im customErrors Abschnitt können Sie eine Standardseite angeben, auf die Benutzer umgeleitet werden, wenn ein Fehler auftritt. Außerdem können Sie einzelne Seiten für bestimmte Statuscodefehler angeben.

<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>

Wenn Sie die Konfiguration verwenden, um den Benutzer auf eine andere Seite umzuleiten, sind die Details des aufgetretenen Fehlers nicht vorhanden.

Sie können jedoch Fehler abfangen, die an einer beliebigen Stelle in Ihrer Anwendung auftreten, indem Sie dem Application_Error Handler in der Datei "Global.asax" Code hinzufügen.

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);
    }
}

Ereignisbehandlung von Fehlern auf Seitenebene

Ein Handler auf Seitenebene gibt den Benutzer an die Seite zurück, auf der der Fehler aufgetreten ist, aber da Instanzen von Steuerelementen nicht verwaltet werden, gibt es auf der Seite nichts mehr. Um den Benutzer der Anwendung die Fehlerdetails bereitzustellen, müssen Sie die Fehlerdetails speziell auf die Seite schreiben.

Normalerweise verwenden Sie einen Fehlerhandler auf Seitenebene, um unbehandelte Fehler zu protokollieren oder den Benutzer auf eine Seite zu bringen, die hilfreiche Informationen anzeigen kann.

Dieses Codebeispiel zeigt einen Handler für das Error-Ereignis in einer ASP.NET Webseite. Dieser Handler fängt alle Ausnahmen ab, die nicht bereits innerhalb von try/catch Blöcken auf der Seite behandelt werden.

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();
}

Nachdem Sie einen Fehler behandelt haben, müssen Sie ihn löschen, indem Sie die ClearError Methode des Server-Objekts (HttpServerUtility Klasse) aufrufen. Andernfalls wird ein Fehler angezeigt, der zuvor aufgetreten ist.

Fehlerbehandlung auf Codeebene

Die try-catch-Anweisung besteht aus einem Try-Block, gefolgt von einer oder mehreren Catch-Klauseln, die Handler für verschiedene Ausnahmen definieren. Wenn eine Ausnahme ausgelöst wird, sucht die Common Language Runtime (CLR) nach der Catch-Anweisung, die diese Ausnahme behandelt. Wenn die derzeit ausgeführte Methode keinen Catch-Block enthält, sucht die CLR in der Methode, die die aktuelle Methode aufgerufen hat, und so weiter den Aufrufstapel hinauf. Wenn kein Catch-Block gefunden wird, zeigt die CLR dem Benutzer eine unbehandelte Ausnahmemeldung an und beendet die Ausführung des Programms.

Das folgende Codebeispiel zeigt eine gängige Methode zur Behandlung try/catch/finally von Fehlern.

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();
    }
}

Im obigen Code enthält der Try-Block den Code, der vor einer möglichen Ausnahme geschützt werden muss. Der Block wird ausgeführt, bis entweder eine Ausnahme ausgelöst wird oder der Block erfolgreich abgeschlossen wird. Wenn eine FileNotFoundException Ausnahme oder eine IOException Ausnahme auftritt, wird die Ausführung auf eine andere Seite übertragen. Anschließend wird der im letzten Block enthaltene Code ausgeführt, unabhängig davon, ob ein Fehler aufgetreten ist.

Hinzufügen der Unterstützung für die Fehlerprotokollierung

Bevor Sie der Wingtip Toys-Beispielanwendung Fehlerbehandlung hinzufügen, fügen Sie die Unterstützung der Fehlerprotokollierung hinzu, indem Sie dem ExceptionUtility" eine Klasse hinzufügen. Dadurch wird jedes Mal, wenn die Anwendung einen Fehler behandelt, die Fehlerdetails der Fehlerprotokolldatei hinzugefügt.

Klicken Sie mit der rechten Maustaste auf den Ordner "Logik ", und wählen Sie dann "Hinzufügen ->Neues Element" aus.
Das Dialogfeld Neues Element hinzufügen wird angezeigt.
Wählen Sie auf der linken Seite die Gruppe "Visual C# ->Code-Vorlagen " aus. Wählen Sie dann "Klasse" aus der mittleren Liste aus, und nennen Sie sie ExceptionUtility.cs.
Wählen Sie Hinzufügen aus. Die neue Klassendatei wird angezeigt.

Ersetzen Sie den vorhandenen Code durch folgenden Code:

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();
    }
  }
}

Wenn eine Ausnahme auftritt, kann die Ausnahme in eine Ausnahmeprotokolldatei geschrieben werden, indem sie die LogException Methode aufruft. Diese Methode verwendet zwei Parameter, das Ausnahmeobjekt und eine Zeichenfolge, die Details zur Quelle der Ausnahme enthält. Das Ausnahmeprotokoll wird in die ErrorLog.txt Datei im ordner App_Data geschrieben.

Hinzufügen einer Fehlerseite

In der Wingtip Toys-Beispielanwendung wird eine Seite verwendet, um Fehler anzuzeigen. Die Fehlerseite ist so konzipiert, dass benutzern der Website eine sichere Fehlermeldung angezeigt wird. Wenn der Benutzer jedoch ein Entwickler ist, der eine HTTP-Anforderung vornimmt, die lokal auf dem Computer bereitgestellt wird, auf dem sich der Code befindet, werden auf der Fehlerseite weitere Fehlerdetails angezeigt.

Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen (Wingtip Toys), und wählen Sie "Hinzufügen ->Neues Element" aus.
Das Dialogfeld Neues Element hinzufügen wird angezeigt.
Wählen Sie auf der linken Seite die Gruppe "Visual C# ->Webvorlagen " aus. Wählen Sie in der mittleren Liste Webformular mit Masterseite aus, und nennen Sie es ErrorPage.aspx.
Klicken Sie auf Hinzufügen.
Wählen Sie die Datei "Site.Master" als Gestaltungsvorlage und dann OK aus.

Ersetzen Sie das vorhandene Markup durch Folgendes:

<%@ 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>

Ersetzen Sie den vorhandenen Code des Code-Behinds (ErrorPage.aspx.cs), sodass er wie folgt angezeigt wird:

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();
    }
  }
}

Wenn die Fehlerseite angezeigt wird, wird der Page_Load Ereignishandler ausgeführt. Page_Load Im Handler wird die Position, an der der Fehler zuerst behandelt wurde, bestimmt. Anschließend wird der letzte aufgetretene Fehler durch Aufrufen der GetLastError Methode des Serverobjekts bestimmt. Wenn die Ausnahme nicht mehr vorhanden ist, wird eine generische Ausnahme erstellt. Wenn die HTTP-Anforderung lokal durchgeführt wurde, werden dann alle Fehlerdetails angezeigt. In diesem Fall werden nur auf dem lokalen Computer, auf dem die Webanwendung ausgeführt wird, diese Fehlerdetails angezeigt. Nachdem die Fehlerinformationen angezeigt wurden, wird der Fehler der Protokolldatei hinzugefügt, und der Fehler wird vom Server gelöscht.

Anzeigen unbehandelter Fehlermeldungen für die Anwendung

Durch Hinzufügen eines customErrors Abschnitts zur Web.config Datei können Sie schnell einfache Fehler behandeln, die in der gesamten Anwendung auftreten. Sie können auch angeben, wie Fehler basierend auf ihrem Statuscodewert behandelt werden, z. B. 404 – Datei nicht gefunden.

Aktualisieren der Konfiguration

Aktualisieren Sie die Konfiguration, indem Sie einen customErrors Abschnitt zur Datei Web.config hinzufügen.

Suchen Sie im Projektmappen-Explorer die Web.config Datei im Stammverzeichnis der Wingtip Toys-Beispielanwendung, und öffnen Sie sie.

Fügen Sie den customErrors Abschnitt zur dateiWeb.config innerhalb des <system.web> Knotens wie folgt hinzu:

<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>

Speichern Sie die Datei Web.config .

Der customErrors Abschnitt gibt den Modus an, der auf "Ein" festgelegt ist. Es gibt außerdem den defaultRedirect, der der Anwendung angibt, zu welcher Seite navigiert werden soll, wenn ein Fehler auftritt. Darüber hinaus haben Sie ein bestimmtes Fehlerelement hinzugefügt, das angibt, wie ein 404-Fehler behandelt wird, wenn eine Seite nicht gefunden wird. Später in diesem Lernprogramm fügen Sie zusätzliche Fehlerbehandlung hinzu, die die Details eines Fehlers auf Anwendungsebene erfasst.

Ausführen der Anwendung

Sie können die Anwendung jetzt ausführen, um die aktualisierten Routen anzuzeigen.

Drücken Sie F5 , um die Wingtip Toys-Beispielanwendung auszuführen.
Der Browser wird geöffnet und zeigt die Default.aspx Seite an.
Geben Sie die folgende URL in den Browser ein (achten Sie darauf, Ihre Portnummer zu verwenden):
https://localhost:44300/NoPage.aspx
Überprüfen Sie die im Browser angezeigten ErrorPage.aspx .

Wenn Sie die NoPage.aspx-Seite anfordern, die nicht vorhanden ist, zeigt die Fehlerseite die einfache Fehlermeldung und die detaillierten Fehlerinformationen an, wenn weitere Details verfügbar sind. Wenn der Benutzer jedoch eine nicht vorhandene Seite von einem Remotestandort angefordert hat, zeigt die Fehlerseite nur die Fehlermeldung rot an.

Einschließen einer Ausnahme für Testzwecke

Um zu überprüfen, wie ihre Anwendung funktioniert, wenn ein Fehler auftritt, können Sie absichtlich Fehlerbedingungen in ASP.NET erstellen. In der Wingtip Toys-Beispielanwendung lösen Sie eine Test ausnahme aus, wenn die Standardseite geladen wird, um zu sehen, was passiert.

Öffnen Sie den Code-Behind der Default.aspx-Seite in Visual Studio.
Die Default.aspx.cs Code-Behind-Seite wird angezeigt werden.

Fügen Sie im Page_Load Handler Code hinzu, damit der Handler wie folgt angezeigt wird:

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

Es ist möglich, verschiedene Arten von Ausnahmen zu erstellen. Im obigen Code erstellen Sie ein InvalidOperationException , wenn die Default.aspx Seite geladen wird.

Ausführen der Anwendung

Sie können die Anwendung ausführen, um zu sehen, wie die Anwendung die Ausnahme behandelt.

Drücken Sie STRG+F5 , um die Wingtip Toys-Beispielanwendung auszuführen.
Die Anwendung löst die InvalidOperationException aus.

Hinweis

Sie müssen STRG+F5 drücken, um die Seite anzuzeigen, ohne in den Code aufzubrechen, um die Quelle des Fehlers in Visual Studio anzuzeigen.
Überprüfen Sie die im Browser angezeigten ErrorPage.aspx .

Wie Sie in den Fehlerdetails sehen können, wurde die Ausnahme vom customError-Abschnitt in der Datei Web.config abgefangen.

Hinzufügen von fehlerbehandlung auf Anwendungsebene

Anstatt die Ausnahme mithilfe des Abschnitts in der customErrorsWeb.config-Datei abzufangen, wo Sie kleine Informationen zur Ausnahme erhalten, können Sie den Fehler auf Anwendungsebene abfangen und Fehlerdetails abrufen.

Suchen und öffnen Sie im Projektmappen-Explorer die Datei Global.asax.cs.

Fügen Sie einen Application_Error Handler hinzu, damit er wie folgt angezeigt wird:

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);
    }
  }
}

Wenn in der Anwendung ein Fehler auftritt, wird der Application_Error Handler aufgerufen. In diesem Handler wird die letzte Ausnahme abgerufen und überprüft. Wenn die Ausnahme nicht behandelt wurde und die Ausnahme (d. h. InnerException ist nicht null) Details zur inneren Ausnahme enthält, überträgt die Anwendung die Ausführung an die Fehlerseite, auf der die Ausnahmedetails angezeigt werden.

Ausführen der Anwendung

Sie können die Anwendung ausführen, um die zusätzlichen Fehlerdetails anzuzeigen, die durch das Behandeln der Ausnahme auf Anwendungsebene bereitgestellt werden.

Drücken Sie STRG+F5 , um die Wingtip Toys-Beispielanwendung auszuführen.
Die Anwendung wirft die InvalidOperationException .
Überprüfen Sie die im Browser angezeigten ErrorPage.aspx .

Hinzufügen von Seitenebenen-Fehlerbehandlung

Sie können entweder ein ErrorPage Attribut für die @Page Direktive der Seite hinzufügen oder einen Page_Error Ereignishandler zum Code-Behind einer Seite hinzufügen. In diesem Abschnitt fügen Sie einen Page_Error Ereignishandler hinzu, der die Ausführung auf die ErrorPage.aspx-Seite überträgt.

Öffnen Sie im Solution Explorer die Datei Default.aspx.cs.

Fügen Sie einen Page_Error-Handler hinzu, damit der Code-Behind wie folgt angezeigt wird:

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);
      }
    }
  }
}

Wenn auf der Seite ein Fehler auftritt, wird der Page_Error Ereignishandler aufgerufen. In diesem Handler wird die letzte Ausnahme abgerufen und überprüft. Wenn ein InvalidOperationException Ereignis auftritt, überträgt der Ereignishandler die Page_Error Ausführung an die Fehlerseite, auf der die Ausnahmedetails angezeigt werden.

Ausführen der Anwendung

Sie können die Anwendung jetzt ausführen, um die aktualisierten Routen anzuzeigen.

Drücken Sie STRG+F5 , um die Wingtip Toys-Beispielanwendung auszuführen.
Die Anwendung wirft die InvalidOperationException.
Überprüfen Sie die im Browser angezeigten ErrorPage.aspx .
Schließen Sie Das Browserfenster.

Entfernen der für Tests verwendeten Ausnahme

Wenn Sie zulassen möchten, dass die Wingtip Toys-Beispielanwendung funktioniert, ohne die Ausnahme auszuwerfen, die Sie weiter oben in diesem Lernprogramm hinzugefügt haben, entfernen Sie die Ausnahme.

Öffnen Sie den Codebehind der Default.aspx-Seite.
Entfernen Sie im Page_Load Handler den Code, der die Ausnahme auslöst, sodass der Handler wie folgt angezeigt wird:
```
protected void Page_Load(object sender, EventArgs e)
{

}
```

** Hinzufügen der Fehlerprotokollierung auf Code-Ebene

Wie weiter oben in diesem Lernprogramm erwähnt, können Sie try/catch-Anweisungen hinzufügen, um zu versuchen, einen Codeabschnitt auszuführen und den ersten aufgetretenen Fehler zu behandeln. In diesem Beispiel schreiben Sie nur die Fehlerdetails in die Fehlerprotokolldatei, damit der Fehler später überprüft werden kann.

Suchen Sie im Projektmappen-Explorer im Ordner "Logik " die PayPalFunctions.cs Datei, und öffnen Sie sie.

Aktualisieren Sie die HttpCall Methode so, dass der Code wie folgt angezeigt wird:

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;
}

Der obige Code ruft die LogException Methode auf, die in der ExceptionUtility Klasse enthalten ist. Sie haben die ExceptionUtility.cs Klassendatei weiter oben in diesem Lernprogramm dem Ordner "Logik " hinzugefügt. Die LogException Methode akzeptiert zwei Parameter. Der erste Parameter ist das Ausnahmeobjekt. Der zweite Parameter ist eine Zeichenfolge, die verwendet wird, um die Quelle des Fehlers zu erkennen.

Überprüfen der Fehlerprotokollierungsinformationen

Wie bereits erwähnt, können Sie das Fehlerprotokoll verwenden, um zu ermitteln, welche Fehler in Ihrer Anwendung zuerst behoben werden sollen. Natürlich werden nur Fehler aufgezeichnet, die abgefangen und in das Fehlerprotokoll geschrieben wurden.

Suchen und öffnen Sie im Projektmappen-Explorer die ErrorLog.txt-Datei im Ordner App_Data.
Möglicherweise müssen Sie die Option "Alle Dateien anzeigen" oder die Option "Aktualisieren" oben im Projektmappen-Explorer auswählen, um die ErrorLog.txt Datei anzuzeigen.
Überprüfen Sie das in Visual Studio angezeigte Fehlerprotokoll:

Sichere Fehlermeldungen

Es ist wichtig zu beachten , dass beim Anzeigen von Fehlermeldungen ihrer Anwendung keine Informationen ausgegeben werden sollten, die ein böswilliger Benutzer beim Angriff auf Ihre Anwendung hilfreich finden könnte. Wenn Ihre Anwendung beispielsweise erfolglos versucht, in eine Datenbank zu schreiben, sollte keine Fehlermeldung angezeigt werden, die den verwendeten Benutzernamen enthält. Aus diesem Grund wird dem Benutzer eine generische Fehlermeldung rot angezeigt. Alle zusätzlichen Fehlerdetails werden nur dem Entwickler auf dem lokalen Computer angezeigt.

Verwenden von ELMAH

ELMAH (Fehlerprotokollierungsmodule und -Handler) ist eine Fehlerprotokollierungseinrichtung, die Sie als NuGet-Paket an Ihre ASP.NET Anwendung anschließen. ELMAH bietet die folgenden Funktionen:

Protokollierung nicht behandelter Ausnahmen.
Eine Webseite zur Ansicht des vollständigen Protokolls neu codierter unbehandelter Ausnahmen.
Eine Webseite zum Anzeigen der vollständigen Details jeder protokollierten Ausnahme.
Eine E-Mail-Benachrichtigung über jeden Fehler zum Zeitpunkt, an dem er auftritt.
Ein RSS-Feed der letzten 15 Fehler aus dem Protokoll.

Bevor Sie mit der ELMAH arbeiten können, müssen Sie es installieren. Dies ist einfach mit dem NuGet-Paketinstallationsprogramm. Wie weiter oben in dieser Lernprogrammreihe erwähnt, ist NuGet eine Visual Studio-Erweiterung, die das Installieren und Aktualisieren von Open Source-Bibliotheken und -Tools in Visual Studio erleichtert.

Wählen Sie in Visual Studio im Menü "Extras die Option "NuGet-Paket-Manager>Verwalten von NuGet-Paketen für Lösung" aus.
Das Dialogfeld "NuGet-Pakete verwalten " wird in Visual Studio angezeigt.
Erweitern Sie im Dialogfeld "NuGet-Pakete verwalten " auf der linken Seite " Online ", und wählen Sie dann nuget.org aus. Suchen und installieren Sie dann das ELMAH-Paket aus der Liste der verfügbaren Pakete online.
Sie müssen über eine Internetverbindung verfügen, um das Paket herunterzuladen.
Stellen Sie im Dialogfeld "Projekte auswählen" sicher, dass die WingtipToys-Auswahl ausgewählt ist, und klicken Sie dann auf "OK".
Klicken Sie bei Bedarf im Dialogfeld "NuGet-Pakete verwalten" auf "Schließen".
Wenn Visual Studio alle geöffneten Dateien erneut lädt, wählen Sie "Ja für alle" aus.
Das ELMAH-Paket fügt Einträge für sich selbst in der dateiWeb.config im Stammverzeichnis Ihres Projekts hinzu. Wenn Sie von Visual Studio gefragt werden, ob Sie die geänderte Web.config Datei neu laden möchten, klicken Sie auf "Ja".

ELMAH ist jetzt bereit, alle unbehandelten Fehler zu speichern, die auftreten.

Anzeigen des ELMAH-Protokolls

Das Anzeigen des ELMAH-Protokolls ist einfach, aber zuerst erstellen Sie eine unbehandelte Ausnahme, die im ELMAH-Protokoll aufgezeichnet wird.

Drücken Sie STRG+F5 , um die Wingtip Toys-Beispielanwendung auszuführen.
Um eine unbehandelte Ausnahme in das ELMAH-Protokoll zu schreiben, navigieren Sie in Ihrem Browser zu der folgenden URL (mit Ihrer Portnummer):
https://localhost:44300/NoPage.aspx Die Fehlerseite wird angezeigt.
Um das ELMAH-Protokoll anzuzeigen, navigieren Sie in Ihrem Browser zu der folgenden URL (mit Ihrer Portnummer):
https://localhost:44300/elmah.axd

Zusammenfassung

In diesem Lernprogramm haben Sie gelernt, wie Fehler auf Anwendungsebene, Seitenebene und Codeebene behandelt werden. Außerdem haben Sie erfahren, wie Sie behandelte und unbehandelte Fehler zur späteren Überprüfung protokollieren. Sie haben das Hilfsprogramm ELMAH hinzugefügt, um Ausnahmeprotokollierung und Benachrichtigung für Ihre Anwendung mithilfe von NuGet bereitzustellen. Darüber hinaus haben Sie gelernt, wie wichtig sichere Fehlermeldungen sind.

Abschluss der Lernprogrammreihe

Vielen Dank, dass Sie ihnen folgen. Ich hoffe, diese Reihe von Lernprogrammen half Ihnen, sich mit ASP.NET Web Forms vertraut zu machen. Weitere Informationen zu Web Forms-Features in ASP.NET 4.5 und Visual Studio 2013 finden Sie unter ASP.NET und Web Tools für Visual Studio 2013 – Versionshinweise. Sehen Sie sich auch das im Abschnitt "Nächste Schritte " erwähnte Lernprogramm an, und probieren Sie die kostenlose Azure-Testversion defintely aus.

Vielen Dank - Erik

Nächste Schritte

Weitere Informationen zum Bereitstellen Ihrer Webanwendung in Microsoft Azure finden Sie unter Bereitstellen einer sicheren ASP.NET Web Forms App mit Mitgliedschaft, OAuth und SQL-Datenbank auf einer Azure-Website.

Kostenlose Testversion

Microsoft Azure – Kostenlose Testversion
Wenn Sie Ihre Website in Microsoft Azure veröffentlichen, sparen Sie Zeit, Wartung und Kosten. Es ist ein schneller Prozess, Ihre Web-App in Azure bereitzustellen. Wenn Sie Ihre Web-App verwalten und überwachen müssen, bietet Azure eine Vielzahl von Tools und Diensten. Verwalten von Daten, Datenverkehr, Identität, Sicherungen, Messaging, Medien und Leistung in Azure. Und all dies wird in einem sehr kostengünstigen Ansatz bereitgestellt.

Zusätzliche Ressourcen

Fehlerdetails protokollieren mit ASP.NET Gesundheitsüberwachung
ELMAH

Danksagung

Ich danke den folgenden Personen, die bedeutende Beiträge zu den Inhalten dieser Lernprogrammreihe geleistet haben:

Alberto Poblacion, MVP & MCT, Spanien
Alex Thissen, Niederlande (Twitter: @alexthissen)
Andre Tournier, USA
Apurva Joshi, Microsoft
Bojan Vrhovnik, Slowenien
Bruno Sonnino, Brasilien (Twitter: @bsonnino)
Carlos dos Santos, Brasilien
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, Portugal
Pranav Rastogi, Microsoft
Tim Ammann, Microsoft
Tom Dykstra, Microsoft

Beiträge der Gemeinschaft

Graham Mendick (@grahammendick)
Auf MSDN: Code-Beispiel zu Visual Studio 2012 Navigation Wingtip Toys
James Chaney (jchaney@agvance.net)
Visual Studio 2012-verwandtes Codebeispiel auf MSDN: ASP.NET 4.5 Web Forms Tutorial Series in Visual Basic
Andrielle Azevedo - Microsoft Technical Audience Beitragender (Twitter: @driazevedo)
Visual Studio 2012-Übersetzung: Iniciando com ASP.NET Web Forms 4.5 - Parte 1 - Introdução e Visão Geral

Zurück

Feedback

War diese Seite hilfreich?

Last updated on 2026-03-27

Freigeben über

ASP.NET Fehlerbehandlung

Was Sie lernen:

Übersicht

Exception-Klasse

Ausnahmevererbungshierarchie

Ausnahmebehandlungshierarchie

Fehlerbehandlung auf Anwendungsebene

Ereignisbehandlung von Fehlern auf Seitenebene

Fehlerbehandlung auf Codeebene

Hinzufügen der Unterstützung für die Fehlerprotokollierung

Hinzufügen einer Fehlerseite

Anzeigen unbehandelter Fehlermeldungen für die Anwendung

Aktualisieren der Konfiguration

Ausführen der Anwendung

Einschließen einer Ausnahme für Testzwecke

Ausführen der Anwendung

Hinzufügen von fehlerbehandlung auf Anwendungsebene

Ausführen der Anwendung

Hinzufügen von Seitenebenen-Fehlerbehandlung

Ausführen der Anwendung

Entfernen der für Tests verwendeten Ausnahme

** Hinzufügen der Fehlerprotokollierung auf Code-Ebene

Überprüfen der Fehlerprotokollierungsinformationen

Sichere Fehlermeldungen

Verwenden von ELMAH

Anzeigen des ELMAH-Protokolls

Zusammenfassung

Abschluss der Lernprogrammreihe

Nächste Schritte

Kostenlose Testversion

Zusätzliche Ressourcen

Danksagung

Beiträge der Gemeinschaft

Feedback

Zusätzliche Ressourcen