ASP.NET – Fehlerbehandlung
von Erik Reitan
Herunterladen des Wingtip Toys-Beispielprojekts (C#) oder E-Book herunterladen (PDF)
Diese Tutorialreihe vermittelt Ihnen die Grundlagen zum Erstellen einer ASP.NET Web Forms-Anwendung mit ASP.NET 4.5 und Microsoft Visual Studio Express 2013 für Web. Ein Visual Studio 2013-Projekt mit C#-Quellcode ist für diese Tutorialreihe verfügbar.
In diesem Tutorial ä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 aufgetretene Fehler finden und beheben. Dieses Tutorial baut auf dem vorherigen Tutorial "URL-Routing" auf und ist Teil der Wingtip Toys-Tutorialreihe.
Sie lernen Folgendes:
- Hinzufügen der globalen Fehlerbehandlung zur Konfiguration der Anwendung.
- Hier erfahren Sie, wie Sie fehlerbehandlung auf Anwendungs-, Seiten- und Codeebene hinzufügen.
- Protokollieren von Fehlern zur späteren Überprüfung
- Hier erfahren Sie, wie Sie Fehlermeldungen anzeigen, die die Sicherheit nicht beeinträchtigen.
- Implementieren von Fehlerprotokollierungsmodulen und -handlern (ELMAH)
Überblick
ASP.NET Anwendungen müssen in der Lage sein, Fehler, die während der Ausführung auftreten, konsistent zu behandeln. 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 jeder Fehler, jede Bedingung oder ein unerwartetes Verhalten, auf das eine Anwendung stößt.
In .NET Framework stellt eine Ausnahme ein Objekt dar, das von der System.Exception
-Klasse erbt. Eine Ausnahme wird in einem Codebereich ausgelöst, in dem ein Fehler aufgetreten ist. Die Ausnahme wird von der Aufrufliste 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.
Als bewährte Methode sollten Sie Fehler in auf Codeebene in Try
//Catch
Finally
Blöcken in Ihrem Code behandeln. Versuchen Sie, diese Blöcke so zu platzieren, dass der Benutzer Probleme in dem Kontext beheben kann, in dem sie auftreten. Wenn die Fehlerbehandlungsblöcke zu weit von dem Ort entfernt sind, an dem 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 wie die StackTrace
-Eigenschaft, die InnerException
-Eigenschaft und die -Eigenschaft, die Message
spezifische Informationen zum aufgetretenen Fehler bereitstellen.
Hierarchie der Ausnahmevererbung
Die Runtime verfügt über einen Basissatz von Ausnahmen, die von der SystemException
-Klasse abgeleitet sind, die von der Runtime ausgelöst wird, 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 finden Sie die wichtigsten Informationen für eine Ausnahme in der Hierarchie der Ausnahmen, dem Ausnahmenamen und den informationen, die in der Ausnahme enthalten sind.
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:
- Anwendungsschicht
- Seitenebene
- Codeebene
Wenn eine Anwendung Ausnahmen verarbeitet, können häufig zusätzliche Informationen zu der Ausnahme abgerufen und dem Benutzer angezeigt werden, die von der Exception-Klasse geerbt wird. Zusätzlich zur Anwendungs-, Seiten- und Codeebene können Sie Ausnahmen auch 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 Web.config-Datei einen customErrors
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 status Codefehler angeben.
<configuration>
<system.web>
<customErrors mode="On" defaultRedirect="ErrorPage.aspx?handler=customErrors%20section%20-%20Web.config">
<error statusCode="404" redirect="ErrorPage.aspx?msg=404&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 verfügbar.
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);
}
}
Behandlung von Fehlerereignissen auf Seitenebene
Ein Handler auf Seitenebene gibt den Benutzer zu der Seite zurück, auf der der Fehler aufgetreten ist, aber da Instanzen von Steuerelementen nicht verwaltet werden, ist nichts mehr auf der Seite vorhanden. Um die Fehlerdetails für den Benutzer der Anwendung bereitzustellen, müssen Sie die Fehlerdetails speziell auf die Seite schreiben.
In der Regel verwenden Sie einen Fehlerhandler auf Seitenebene, um nicht behandelte Fehler zu protokollieren oder den Benutzer auf eine Seite zu bringen, auf der hilfreiche Informationen angezeigt werden können.
Dieses Codebeispiel zeigt einen Handler für das Fehlerereignis in einer ASP.NET Webseite. Dieser Handler fängt alle Ausnahmen ab, die noch nicht innerhalb von Blöcken try
/catch
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 angeben. 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 nach der Methode, die die aktuelle Methode aufgerufen hat, usw. die Aufrufliste nach oben. Wenn kein Catch-Block gefunden wird, zeigt die CLR dem Benutzer eine nicht behandelte 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 oder der Block erfolgreich abgeschlossen wurde. Wenn eine FileNotFoundException
Ausnahme oder eine IOException
Ausnahme auftritt, wird die Ausführung auf eine andere Seite übertragen. Anschließend wird der im abschließenden Block enthaltene Code ausgeführt, unabhängig davon, ob ein Fehler aufgetreten ist oder nicht.
Hinzufügen von Unterstützung für die Fehlerprotokollierung
Bevor Sie der Wingtip Toys-Beispielanwendung die Fehlerbehandlung hinzufügen, fügen Sie die Unterstützung für die Fehlerprotokollierung hinzu, indem Sie dem Ordner Logic eine ExceptionUtility
Klasse hinzufügen. Dadurch werden jedes Mal, wenn die Anwendung einen Fehler behandelt, die Fehlerdetails der Fehlerprotokolldatei hinzugefügt.
Klicken Sie mit der rechten Maustaste auf den Ordner Logic , und wählen Sie dann Hinzufügen ->Neues Element aus.
Das Dialogfeld Neues Element hinzufügen wird angezeigt.Wählen Sie links die Gruppe Visual C# ->Code-Vorlagen aus. Wählen Sie dann in der mittleren Liste Klasseaus, 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 die LogException
-Methode aufgerufen wird. Diese Methode akzeptiert 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 zusätzliche Fehlerdetails auf der Fehlerseite angezeigt.
Klicken Sie in 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 links die Gruppe Visual C#->Webvorlagen aus. Wählen Sie in der mittleren Liste Webformular mit Gestaltungsvorlage aus, und nennen Sie es ErrorPage.aspx.
Klicken Sie auf Hinzufügen.
Wählen Sie die Datei Site.Master als master Seite aus, und klicken Sie dann auf OK.
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> </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 CodeBehinds (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 der Speicherort bestimmt, an dem der Fehler zuerst behandelt wurde. Anschließend wird der zuletzt aufgetretene Fehler durch Aufrufen der GetLastError
-Methode des Server-Objekts bestimmt. Wenn die Ausnahme nicht mehr vorhanden ist, wird eine generische Ausnahme erstellt. Wenn die HTTP-Anforderung dann lokal erfolgt ist, werden alle Fehlerdetails angezeigt. In diesem Fall werden diese Fehlerdetails nur auf dem lokalen Computer angezeigt, auf dem die Webanwendung ausgeführt wird. Nachdem die Fehlerinformationen angezeigt wurden, wird der Fehler der Protokolldatei hinzugefügt, und der Fehler wird vom Server gelöscht.
Anzeigen nicht behandelter Fehlermeldungen für die Anwendung
Durch Hinzufügen eines customErrors
Abschnitts zur Web.config-Datei können Sie einfache Fehler, die in der gesamten Anwendung auftreten, schnell behandeln. Sie können auch angeben, wie Fehler basierend auf ihrem status Codewert behandelt werden, z. B. 404 – Datei nicht gefunden.
Aktualisieren der Konfiguration
Aktualisieren Sie die Konfiguration, indem Sie der dateiWeb.config einen customErrors
Abschnitt hinzufügen.
Suchen und öffnen Sie in Projektmappen-Explorer die dateiWeb.config im Stammverzeichnis der Wingtip Toys-Beispielanwendung.
Fügen Sie den
customErrors
Abschnitt wie folgt der Web.config-Datei innerhalb des<system.web>
Knotens hinzu:<configuration> <system.web> <customErrors mode="On" defaultRedirect="ErrorPage.aspx?handler=customErrors%20section%20-%20Web.config"> <error statusCode="404" redirect="ErrorPage.aspx?msg=404&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. Außerdem wird angegeben defaultRedirect
, dass der Anwendung mitteilt, zu welcher Seite bei einem Fehler navigiert werden soll. 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 Tutorial fügen Sie eine 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 Seite Default.aspx an.Geben Sie die folgende URL im Browser ein (achten Sie darauf, dass Sie Ihre Portnummer verwenden):
https://localhost:44300/NoPage.aspx
Überprüfen Sie die im Browser angezeigte ErrorPage.aspx .
Wenn Sie die Seite NoPage.aspx anfordern, die nicht vorhanden ist, werden auf der Fehlerseite die einfache Fehlermeldung und die detaillierten Fehlerinformationen angezeigt, sofern zusätzliche Details verfügbar sind. Wenn der Benutzer jedoch eine nicht vorhandene Seite von einem Remotespeicherort angefordert hat, würde die Fehlermeldung auf der Fehlerseite nur rot angezeigt.
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 geschieht.
Öffnen Sie das CodeBehind der Seite Default.aspx in Visual Studio.
Die CodeBehind-Seite Default.aspx.cs wird angezeigt.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 eine InvalidOperationException
, wenn die Seite Default.aspx 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 einzubrechen, um die Fehlerquelle in Visual Studio anzuzeigen.
Überprüfen Sie die im Browser angezeigte ErrorPage.aspx .
Wie Sie in den Fehlerdetails sehen können, wurde die Ausnahme vom customError
Abschnitt in der Web.config-Datei abgefangen.
Hinzufügen Application-Level Fehlerbehandlung
Anstatt die Ausnahme mithilfe des Abschnitts customErrors
in der Web.config-Datei abzufangen, in dem Sie nur wenige Informationen über die Ausnahme erhalten, können Sie den Fehler auf Anwendungsebene abfangen und Fehlerdetails abrufen.
Suchen Und öffnen Sie in 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 innere Ausnahmedetails enthält (d. h. InnerException
nicht NULL), ü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 behandeln der Ausnahme auf Anwendungsebene bereitgestellt werden.
Drücken Sie STRG+F5 , um die Wingtip Toys-Beispielanwendung auszuführen.
Die Anwendung löst ausInvalidOperationException
.Überprüfen Sie die im Browser angezeigte ErrorPage.aspx .
Hinzufügen Page-Level Fehlerbehandlung
Sie können einer Seite die Fehlerbehandlung auf Seitenebene hinzufügen, indem Sie entweder ein ErrorPage
Attribut zur @Page
-Anweisung der Seite hinzufügen oder einen Ereignishandler zum CodeBehind einer Seite hinzufügen Page_Error
. In diesem Abschnitt fügen Sie einen Page_Error
Ereignishandler hinzu, der die Ausführung auf die Seite ErrorPage.aspx überträgt.
Suchen Und öffnen Sie in Projektmappen-Explorer die Datei Default.aspx.cs.
Fügen Sie einen
Page_Error
Handler hinzu, damit das CodeBehind 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 löst ausInvalidOperationException
.Überprüfen Sie die im Browser angezeigte ErrorPage.aspx .
Schließen Sie Ihr Browserfenster.
Entfernen der für Tests verwendeten Ausnahme
Damit die Wingtip Toys-Beispielanwendung funktioniert, ohne die Zuvor in diesem Tutorial hinzugefügte Ausnahme auszulösen, entfernen Sie die Ausnahme.
Öffnen Sie das CodeBehind der Seite Default.aspx .
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 Code-Level Fehlerprotokollierung
Wie weiter oben in diesem Tutorial erwähnt, können Sie try/catch-Anweisungen hinzufügen, um zu versuchen, einen Codeabschnitt auszuführen und den ersten Fehler zu behandeln, der auftritt. In diesem Beispiel schreiben Sie nur die Fehlerdetails in die Fehlerprotokolldatei, damit der Fehler später überprüft werden kann.
Suchen Sie in Projektmappen-Explorer im Ordner Logic die Datei PayPalFunctions.cs, und öffnen Sie sie.
Aktualisieren Sie die
HttpCall
-Methode, sodass 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 Klassendatei ExceptionUtility.cs weiter oben in diesem Tutorial zum Ordner Logic hinzugefügt. Die LogException
-Methode nimmt zwei Parameter an. Der erste Parameter ist das Ausnahmeobjekt. Der zweite Parameter ist eine Zeichenfolge, die verwendet wird, um die Fehlerquelle zu erkennen.
Überprüfen der Fehlerprotokollierungsinformationen
Wie bereits erwähnt, können Sie das Fehlerprotokoll verwenden, um zu bestimmen, 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 in Projektmappen-Explorer die ErrorLog.txt-Datei im Ordner App_Data.
Möglicherweise müssen Sie oben in Projektmappen-Explorer die Option "Alle Dateien anzeigen" oder die Option "Aktualisieren" 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 Ihre Anwendung, wenn Fehlermeldungen angezeigt werden, keine Informationen verschenken sollte, die ein böswilliger Benutzer bei Angriffen auf Ihre Anwendung als hilfreich empfinden könnte. Wenn Ihre Anwendung beispielsweise nicht erfolgreich versucht, in eine Datenbank zu schreiben, sollte keine Fehlermeldung angezeigt werden, die den verwendeten Benutzernamen enthält. Aus diesem Grund wird dem Benutzer eine allgemeine Fehlermeldung in Rot angezeigt. Alle zusätzlichen Fehlerdetails werden nur dem Entwickler auf dem lokalen Computer angezeigt.
Verwenden von ELMAH
ELMAH (Fehlerprotokollierungsmodule und -handler) ist eine Fehlerprotokollierungsfunktion, die Sie als NuGet-Paket an Ihre ASP.NET-Anwendung anschließen. ELMAH bietet die folgenden Funktionen:
- Protokollierung nicht behandelter Ausnahmen.
- Eine Webseite, auf der das gesamte Protokoll von neu codierten ausnahmen angezeigt wird.
- Eine Webseite, auf der die vollständigen Details jeder protokollierten Ausnahme angezeigt werden.
- Eine E-Mail-Benachrichtigung über jeden Fehler zum Zeitpunkt des Auftretens.
- Ein RSS-Feed der letzten 15 Fehler aus dem Protokoll.
Bevor Sie mit der ELMAH arbeiten können, müssen Sie sie installieren. Dies ist ganz einfach mit dem NuGet-Paketinstallationsprogramm. Wie bereits in dieser Tutorialreihe erwähnt, ist NuGet eine Visual Studio-Erweiterung, die das Installieren und Aktualisieren Open Source Bibliotheken und Tools in Visual Studio erleichtert.
Wählen Sie in Visual Studio im Menü Extras die Option NuGet-Paket-Manager>NuGet-Pakete für Projektmappe verwalten 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 benötigen eine Internetverbindung, um das Paket herunterladen zu können.
Stellen Sie im Dialogfeld Projekte auswählen sicher, dass die Auswahl WingtipToys ausgewählt ist, und klicken Sie dann auf OK.
Klicken Sie bei Bedarf im Dialogfeld NuGet-Pakete verwalten auf Schließen.
Wenn Visual Studio anfordert, geöffnete Dateien neu zu laden, wählen Sie "Ja zu allen" aus.
Das ELMAH-Paket fügt einträge für sich selbst in der Web.config-Datei im Stammverzeichnis Ihres Projekts hinzu. Wenn Visual Studio Sie fragt, ob Sie die geänderte Web.config-Datei erneut laden möchten, klicken Sie auf Ja.
ELMAH ist jetzt bereit, alle nicht behandelten Fehler zu speichern, die auftreten.
Anzeigen des ELMAH-Protokolls
Das Anzeigen des ELMAH-Protokolls ist einfach, aber zuerst erstellen Sie eine nicht behandelte Ausnahme, die im ELMAH-Protokoll aufgezeichnet wird.
Drücken Sie STRG+F5 , um die Wingtip Toys-Beispielanwendung auszuführen.
Um eine nicht behandelte Ausnahme in das ELMAH-Protokoll zu schreiben, navigieren Sie in Ihrem Browser zur folgenden URL (mit Ihrer Portnummer):
https://localhost:44300/NoPage.aspx
Die Fehlerseite wird angezeigt.Um das ELMAH-Protokoll anzuzeigen, navigieren Sie in Ihrem Browser zur folgenden URL (mit Ihrer Portnummer):
https://localhost:44300/elmah.axd
Zusammenfassung
In diesem Tutorial haben Sie die Behandlung von Fehlern auf Anwendungsebene, Seitenebene und Codeebene kennengelernt. Sie haben auch gelernt, wie Sie behandelte und nicht behandelte Fehler zur späteren Überprüfung protokollieren. Sie haben das ELMAH-Hilfsprogramm hinzugefügt, um Ausnahmeprotokollierung und Benachrichtigungen für Ihre Anwendung mithilfe von NuGet bereitzustellen. Darüber hinaus haben Sie erfahren, wie wichtig sichere Fehlermeldungen sind.
Abschluss der Tutorialreihe
Vielen Dank, dass Sie mitkommen. Ich hoffe, diese Tutorials haben Ihnen geholfen, sich mit ASP.NET Web Forms vertraut zu machen. Weitere Informationen zu Web Forms Features, die in ASP.NET 4.5 und Visual Studio 2013 verfügbar sind, finden Sie unter ASP.NET and Web Tools für Visual Studio 2013 Versionshinweise. Sehen Sie sich auch das im Abschnitt Nächste Schritte erwähnte Tutorial an, und testen Sie die kostenlose Azure-Testversion.
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. Dies ist ein schneller Prozess zum Bereitstellen Ihrer Web-App in Azure. 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.
Weitere Ressourcen
Protokollieren von Fehlerdetails mit ASP.NET Integritätsüberwachung
ELMAH
Danksagung
Ich möchte den folgenden Personen danken, die wichtige Beiträge zum Inhalt dieser Tutorialreihe gemacht 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 Community
- Graham Mendick (@grahammendick)
Visual Studio 2012-bezogenes Codebeispiel auf MSDN: Navigation Wingtip Toys - James Chaney (jchaney@agvance.net)
Visual Studio 2012-bezogenes Codebeispiel auf MSDN: ASP.NET 4.5 Web Forms Tutorialreihe in Visual Basic - Andrielle Azevedo – Microsoft Technical Audience Contributor (twitter: @driazevedo)
Visual Studio 2012 Übersetzung: Iniciando com ASP.NET Web Forms 4.5 – Parte 1 – Introdução e Visão Geral