Gestion des erreurs ASP.NET

Article
06/16/2023

Télécharger l’exemple de projet Wingtip Toys (C#) ou télécharger le livre électronique (PDF)

Cette série de tutoriels vous apprend les bases de la création d’une application ASP.NET Web Forms à l’aide de ASP.NET 4.5 et Microsoft Visual Studio Express 2013 pour le web. Un projet Visual Studio 2013 avec du code source C# est disponible pour accompagner cette série de tutoriels.

Dans ce tutoriel, vous allez modifier l’exemple d’application Wingtip Toys pour inclure la gestion des erreurs et la journalisation des erreurs. La gestion des erreurs permet à l’application de gérer correctement les erreurs et d’afficher les messages d’erreur en conséquence. La journalisation des erreurs vous permet de rechercher et de corriger les erreurs qui se sont produites. Ce tutoriel s’appuie sur le didacticiel précédent « Routage d’URL » et fait partie de la série de tutoriels Wingtip Toys.

Ce que vous allez apprendre :

Comment ajouter la gestion globale des erreurs à la configuration de l’application.
Comment ajouter la gestion des erreurs au niveau de l’application, de la page et du code.
Comment enregistrer les erreurs en vue d’une révision ultérieure.
Comment afficher des messages d’erreur qui ne compromettent pas la sécurité.
Comment implémenter la journalisation des erreurs des modules et des gestionnaires de journalisation des erreurs (ELMAH).

Vue d’ensemble

ASP.NET applications doivent être en mesure de gérer les erreurs qui se produisent pendant l’exécution de manière cohérente. ASP.NET utilise le Common Language Runtime (CLR), qui fournit un moyen de notifier les applications des erreurs de manière uniforme. Lorsqu’une erreur se produit, une exception est levée. Une exception est toute erreur, condition ou comportement inattendu rencontré par une application.

Dans le .NET Framework, une exception est un objet qui hérite de la classe System.Exception. Une exception est levée à partir d'une partie du code où un problème s'est produit. L’exception est passée dans la pile des appels à un emplacement où l’application fournit du code pour gérer l’exception. Si l’application ne gère pas l’exception, le navigateur est forcé d’afficher les détails de l’erreur.

Il est recommandé de gérer les erreurs au niveau du code dans les Try//CatchFinally blocs de votre code. Essayez de placer ces blocs afin que l’utilisateur puisse corriger les problèmes dans le contexte dans lequel ils se produisent. Si les blocs de gestion des erreurs sont trop éloignés de l’endroit où l’erreur s’est produite, il devient plus difficile de fournir aux utilisateurs les informations dont ils ont besoin pour résoudre le problème.

Exception, classe

La classe Exception est la classe de base dont héritent les exceptions. La plupart des objets exception sont des instances d’une classe dérivée de la classe Exception, telle que la SystemException classe, la IndexOutOfRangeException classe ou la ArgumentNullException classe . La classe Exception possède des propriétés, telles que la StackTrace propriété, la InnerException propriété et la Message propriété, qui fournissent des informations spécifiques sur l’erreur qui s’est produite.

Hiérarchie d’héritage des exceptions

Le runtime a un ensemble de base d’exceptions dérivant de la SystemException classe que le runtime lève lorsqu’une exception est rencontrée. La plupart des classes qui héritent de la classe Exception, telles que la IndexOutOfRangeException classe et la ArgumentNullException classe, n’implémentent pas de membres supplémentaires. Par conséquent, les informations les plus importantes pour une exception se trouvent dans la hiérarchie des exceptions, le nom de l’exception et les informations contenues dans l’exception.

Hiérarchie de gestion des exceptions

Dans une application ASP.NET Web Forms, les exceptions peuvent être gérées en fonction d’une hiérarchie de gestion spécifique. Une exception peut être gérée aux niveaux suivants :

Niveau d’application
Niveau page
Niveau du code

Lorsqu’une application gère des exceptions, des informations supplémentaires sur l’exception héritée de la classe Exception peuvent souvent être récupérées et affichées à l’utilisateur. En plus de l’application, de la page et du code, vous pouvez également gérer les exceptions au niveau du module HTTP et à l’aide d’un gestionnaire personnalisé IIS.

Gestion des erreurs au niveau de l’application

Vous pouvez gérer les erreurs par défaut au niveau de l’application en modifiant la configuration de votre application ou en ajoutant un Application_Error gestionnaire dans le fichier Global.asax de votre application.

Vous pouvez gérer les erreurs par défaut et les erreurs HTTP en ajoutant une customErrors section au fichier Web.config . La customErrors section vous permet de spécifier une page par défaut vers laquelle les utilisateurs seront redirigés lorsqu’une erreur se produit. Il vous permet également de spécifier des pages individuelles pour des erreurs de code status spécifiques.

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

Malheureusement, lorsque vous utilisez la configuration pour rediriger l’utilisateur vers une autre page, vous n’avez pas les détails de l’erreur qui s’est produite.

Toutefois, vous pouvez intercepter les erreurs qui se produisent n’importe où dans votre application en ajoutant du Application_Error code au gestionnaire dans le fichier 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);
    }
}

Gestion des événements d’erreur au niveau de la page

Un gestionnaire au niveau de la page renvoie l’utilisateur à la page où l’erreur s’est produite, mais comme les instances de contrôles ne sont pas conservées, il n’y aura plus rien sur la page. Pour fournir les détails de l’erreur à l’utilisateur de l’application, vous devez écrire spécifiquement les détails de l’erreur dans la page.

Vous utilisez généralement un gestionnaire d’erreurs au niveau de la page pour enregistrer les erreurs non gérées ou pour amener l’utilisateur à une page qui peut afficher des informations utiles.

Cet exemple de code montre un gestionnaire pour l’événement Error dans une page Web ASP.NET. Ce gestionnaire intercepte toutes les exceptions qui ne sont pas déjà gérées dans try/catch des blocs de la page.

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

Une fois que vous avez géré une erreur, vous devez l’effacer en appelant la ClearError méthode de l’objet Server (HttpServerUtility classe ). Sinon, vous verrez une erreur qui s’est produite précédemment.

Gestion des erreurs au niveau du code

L’instruction try-catch se compose d’un bloc try suivi d’une ou de plusieurs clauses catch, qui spécifient des gestionnaires pour différentes exceptions. Lorsqu’une exception est levée, le Common Language Runtime (CLR) recherche l’instruction catch qui gère cette exception. Si la méthode en cours d’exécution ne contient pas de bloc catch, le CLR examine la méthode qui a appelé la méthode actuelle, et ainsi de suite, dans la pile des appels. Si aucun bloc catch n’est trouvé, le CLR affiche un message d’exception non géré à l’utilisateur et arrête l’exécution du programme.

L’exemple de code suivant montre une méthode courante d’utilisation try//catchfinally pour gérer les erreurs.

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

Dans le code ci-dessus, le bloc try contient le code qui doit être protégé contre une exception possible. Le bloc est exécuté jusqu’à ce qu’une exception soit levée ou que le bloc soit terminé avec succès. Si une FileNotFoundException exception ou une IOException exception se produit, l’exécution est transférée vers une autre page. Ensuite, le code contenu dans le bloc final est exécuté, qu’une erreur se soit produite ou non.

Ajout de la prise en charge de la journalisation des erreurs

Avant d’ajouter la gestion des erreurs à l’exemple d’application Wingtip Toys, vous allez ajouter la prise en charge de la journalisation des erreurs en ajoutant une ExceptionUtility classe au dossier Logique . Ainsi, chaque fois que l’application gère une erreur, les détails de l’erreur sont ajoutés au fichier journal des erreurs.

Cliquez avec le bouton droit sur le dossier Logique , puis sélectionnez Ajouter ->Nouvel élément.
La boîte de dialogue Ajouter un nouvel élément s’affiche.
Sélectionnez le groupe Modèles Visual C# ->Code sur la gauche. Ensuite, sélectionnez Classedans la liste intermédiaire et nommez-la ExceptionUtility.cs.
Choisissez Ajouter. Le nouveau fichier de classe s’affiche.

Remplacez le code existant par le code ci-dessous :

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

Lorsqu’une exception se produit, l’exception peut être écrite dans un fichier journal d’exceptions en appelant la LogException méthode . Cette méthode accepte deux paramètres, l’objet exception et une chaîne contenant des détails sur la source de l’exception. Le journal des exceptions est écrit dans le fichier ErrorLog.txt dans le dossier App_Data .

Ajout d’une page d’erreur

Dans l’exemple d’application Wingtip Toys, une page est utilisée pour afficher les erreurs. La page d’erreur est conçue pour afficher un message d’erreur sécurisé aux utilisateurs du site. Toutefois, si l’utilisateur est un développeur effectuant une requête HTTP qui est traitée localement sur l’ordinateur où se trouve le code, des détails supplémentaires sur l’erreur s’affichent sur la page d’erreur.

Cliquez avec le bouton droit sur le nom du projet (Wingtip Toys) dans Explorateur de solutions et sélectionnez Ajouter ->Nouvel élément.
La boîte de dialogue Ajouter un nouvel élément s’affiche.
Sélectionnez le groupe Visual C# ->Modèles web sur la gauche. Dans la liste du milieu, sélectionnez Formulaire web avec page maître et nommez-le ErrorPage.aspx.
Cliquez sur Ajouter.
Sélectionnez le fichier Site.Master comme page master, puis choisissez OK.

Remplacez le balisage existant par ce qui suit :

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

Remplacez le code existant du code-behind (ErrorPage.aspx.cs) afin qu’il apparaisse comme suit :

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

Lorsque la page d’erreur s’affiche, le Page_Load gestionnaire d’événements est exécuté. Dans le Page_Load gestionnaire, l’emplacement où l’erreur a été gérée pour la première fois est déterminé. Ensuite, la dernière erreur qui s’est produite est déterminée en appelant la GetLastError méthode de l’objet Server. Si l’exception n’existe plus, une exception générique est créée. Ensuite, si la requête HTTP a été effectuée localement, tous les détails de l’erreur s’affichent. Dans ce cas, seul l’ordinateur local exécutant l’application web verra ces détails d’erreur. Une fois les informations d’erreur affichées, l’erreur est ajoutée au fichier journal et l’erreur est effacée du serveur.

Affichage des messages d’erreur non gérés pour l’application

En ajoutant une customErrors section au fichier Web.config , vous pouvez rapidement gérer les erreurs simples qui se produisent dans l’application. Vous pouvez également spécifier comment gérer les erreurs en fonction de leur valeur de code status, telle que 404 - Fichier introuvable.

Mettre à jour la configuration

Mettez à jour la configuration en ajoutant une customErrors section au fichier Web.config .

Dans Explorateur de solutions, recherchez et ouvrez le fichier Web.config à la racine de l’exemple d’application Wingtip Toys.

Ajoutez la customErrors section au fichier Web.config dans le <system.web> nœud comme suit :

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

Enregistrez le fichier Web.config .

La customErrors section spécifie le mode, qui est défini sur « On ». Il spécifie également le defaultRedirect, qui indique à l’application à quelle page accéder lorsqu’une erreur se produit. En outre, vous avez ajouté un élément d’erreur spécifique qui spécifie comment gérer une erreur 404 lorsqu’une page est introuvable. Plus loin dans ce tutoriel, vous ajouterez une gestion des erreurs supplémentaire qui capturera les détails d’une erreur au niveau de l’application.

Exécution de l'application

Vous pouvez exécuter l’application maintenant pour voir les itinéraires mis à jour.

Appuyez sur F5 pour exécuter l’exemple d’application Wingtip Toys.
Le navigateur s’ouvre et affiche la page Default.aspx .
Entrez l’URL suivante dans le navigateur (veillez à utiliser votre numéro de port) :
https://localhost:44300/NoPage.aspx
Passez en revue le fichier ErrorPage.aspx affiché dans le navigateur.

Lorsque vous demandez la page NoPage.aspx , qui n’existe pas, la page d’erreur affiche le message d’erreur simple et les informations détaillées sur l’erreur si des détails supplémentaires sont disponibles. Toutefois, si l’utilisateur a demandé une page inexistante à partir d’un emplacement distant, la page d’erreur affiche uniquement le message d’erreur en rouge.

Inclusion d’une exception à des fins de test

Pour vérifier le fonctionnement de votre application lorsqu’une erreur se produit, vous pouvez créer délibérément des conditions d’erreur dans ASP.NET. Dans l’exemple d’application Wingtip Toys, vous liez une exception de test lorsque la page par défaut se charge pour voir ce qui se passe.

Ouvrez le code-behind de la page Default.aspx dans Visual Studio.
La page code-behind Default.aspx.cs s’affiche.

Dans le Page_Load gestionnaire, ajoutez du code afin que le gestionnaire s’affiche comme suit :

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

Il est possible de créer différents types d’exceptions. Dans le code ci-dessus, vous créez un InvalidOperationException lorsque la page Default.aspx est chargée.

Exécution de l'application

Vous pouvez exécuter l’application pour voir comment l’application gère l’exception.

Appuyez sur Ctrl+F5 pour exécuter l’exemple d’application Wingtip Toys.
L’application lève la exception InvalidOperationException.

Notes

Vous devez appuyer sur Ctrl+F5 pour afficher la page sans vous interrompre dans le code afin d’afficher la source de l’erreur dans Visual Studio.
Passez en revue le fichier ErrorPage.aspx affiché dans le navigateur.

Comme vous pouvez le voir dans les détails de l’erreur, l’exception a été piégée par la customError section dans le fichier Web.config .

Ajout de Application-Level gestion des erreurs

Au lieu d’intercepter l’exception à l’aide de la customErrors section du fichier Web.config , où vous obtenez peu d’informations sur l’exception, vous pouvez intercepter l’erreur au niveau de l’application et récupérer les détails de l’erreur.

Dans Explorateur de solutions, recherchez et ouvrez le fichier Global.asax.cs.

Ajoutez un gestionnaire de Application_Error afin qu’il apparaisse comme suit :

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

Lorsqu’une erreur se produit dans l’application, le Application_Error gestionnaire est appelé. Dans ce gestionnaire, la dernière exception est récupérée et examinée. Si l’exception n’a pas été gérée et qu’elle contient les détails de l’exception interne (autrement dit, InnerException n’est pas null), l’application transfère l’exécution vers la page d’erreur où les détails de l’exception sont affichés.

Exécution de l'application

Vous pouvez exécuter l’application pour afficher les détails d’erreur supplémentaires fournis en gérant l’exception au niveau de l’application.

Appuyez sur Ctrl+F5 pour exécuter l’exemple d’application Wingtip Toys.
L’application lève le InvalidOperationException .
Passez en revue le fichier ErrorPage.aspx affiché dans le navigateur.

Ajout de Page-Level gestion des erreurs

Vous pouvez ajouter la gestion des erreurs au niveau de la page à une page en ajoutant un ErrorPage attribut à la @Page directive de la page ou en ajoutant un Page_Error gestionnaire d’événements au code-behind d’une page. Dans cette section, vous allez ajouter un gestionnaire d’événements Page_Error qui transférera l’exécution à la page ErrorPage.aspx .

Dans Explorateur de solutions, recherchez et ouvrez le fichier Default.aspx.cs.

Ajoutez un Page_Error gestionnaire afin que le code-behind s’affiche comme suit :

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

Lorsqu’une erreur se produit sur la page, le gestionnaire d’événements Page_Error est appelé. Dans ce gestionnaire, la dernière exception est récupérée et examinée. Si une InvalidOperationException se produit, le gestionnaire d’événements transfère l’exécution Page_Error vers la page d’erreur où les détails de l’exception sont affichés.

Exécution de l'application

Vous pouvez exécuter l’application maintenant pour voir les itinéraires mis à jour.

Appuyez sur Ctrl+F5 pour exécuter l’exemple d’application Wingtip Toys.
L’application lève le InvalidOperationException .
Passez en revue le fichier ErrorPage.aspx affiché dans le navigateur.
Fermez votre fenêtre de navigateur.

Suppression de l’exception utilisée pour le test

Pour permettre à l’exemple d’application Wingtip Toys de fonctionner sans lever l’exception que vous avez ajoutée précédemment dans ce tutoriel, supprimez l’exception.

Ouvrez le code-behind de la page Default.aspx .
Dans le Page_Load gestionnaire, supprimez le code qui lève l’exception afin que le gestionnaire s’affiche comme suit :
```
protected void Page_Load(object sender, EventArgs e)
{

}
```

Ajout Code-Level journalisation des erreurs

Comme mentionné précédemment dans ce tutoriel, vous pouvez ajouter des instructions try/catch pour tenter d’exécuter une section de code et gérer la première erreur qui se produit. Dans cet exemple, vous allez écrire uniquement les détails de l’erreur dans le fichier journal des erreurs afin que l’erreur puisse être examinée ultérieurement.

Dans Explorateur de solutions, dans le dossier Logique, recherchez et ouvrez le fichier PayPalFunctions.cs.

Mettez à jour la HttpCall méthode afin que le code s’affiche comme suit :

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

Le code ci-dessus appelle la LogException méthode contenue dans la ExceptionUtility classe . Vous avez ajouté le fichier de classe ExceptionUtility.cs au dossier Logique plus haut dans ce tutoriel. La méthode LogException accepte deux paramètres. Le premier paramètre est l’objet exception. Le deuxième paramètre est une chaîne utilisée pour reconnaître la source de l’erreur.

Inspection des informations de journalisation des erreurs

Comme mentionné précédemment, vous pouvez utiliser le journal des erreurs pour déterminer les erreurs de votre application qui doivent être corrigées en premier. Bien entendu, seules les erreurs qui ont été interceptées et écrites dans le journal des erreurs seront enregistrées.

Dans Explorateur de solutions, recherchez et ouvrez le fichier ErrorLog.txt dans le dossier App_Data.
Vous devrez peut-être sélectionner l’option « Afficher tous les fichiers » ou l’option « Actualiser » en haut de Explorateur de solutions pour afficher le fichier ErrorLog.txt.
Passez en revue le journal des erreurs affiché dans Visual Studio :

Messages d’erreur sécurisés

Il est important de noter que lorsque votre application affiche des messages d’erreur, elle ne doit pas donner d’informations qu’un utilisateur malveillant peut trouver utiles pour attaquer votre application. Par exemple, si votre application tente d’écrire dans une base de données, elle ne doit pas afficher de message d’erreur incluant le nom d’utilisateur qu’elle utilise. Pour cette raison, un message d’erreur générique en rouge s’affiche à l’utilisateur. Tous les détails d’erreur supplémentaires sont affichés uniquement pour le développeur sur l’ordinateur local.

Utilisation d’ELMAH

ELMAH (Modules et gestionnaires de journalisation des erreurs) est une fonctionnalité de journalisation des erreurs que vous branchez à votre application ASP.NET en tant que package NuGet. ELMAH offre les fonctionnalités suivantes :

Journalisation des exceptions non gérées.
Page web pour afficher l’intégralité du journal des exceptions non gérées recodées.
Page web pour afficher les détails complets de chaque exception journalisée.
Notification par e-mail de chaque erreur au moment où elle se produit.
Flux RSS des 15 dernières erreurs du journal.

Avant de pouvoir utiliser ELMAH, vous devez l’installer. Cela est facile à l’aide du programme d’installation du package NuGet . Comme mentionné précédemment dans cette série de tutoriels, NuGet est une extension Visual Studio qui facilite l’installation et la mise à jour open source bibliothèques et outils dans Visual Studio.

Dans Visual Studio, dans le menu Outils, sélectionnez Gestionnaire> de package NuGetGérer les packages NuGet pour la solution.
La boîte de dialogue Gérer les packages NuGet s’affiche dans Visual Studio.
Dans la boîte de dialogue Gérer les packages NuGet , développez Online sur la gauche, puis sélectionnez nuget.org. Ensuite, recherchez et installez le package ELMAH à partir de la liste des packages disponibles en ligne.
Vous devez disposer d’une connexion Internet pour télécharger le package.
Dans la boîte de dialogue Sélectionner des projets , vérifiez que la sélection WingtipToys est sélectionnée, puis cliquez sur OK.
Cliquez sur Fermer dans la boîte de dialogue Gérer les packages NuGet si nécessaire.
Si Visual Studio vous demande de recharger tous les fichiers ouverts, sélectionnez « Oui à tout ».
Le package ELMAH ajoute des entrées pour lui-même dans le fichier Web.config à la racine de votre projet. Si Visual Studio vous demande si vous souhaitez recharger le fichier Web.config modifié, cliquez sur Oui.

ELMAH est maintenant prêt à stocker toutes les erreurs non gérées qui se produisent.

Affichage du journal ELMAH

L’affichage du journal ELMAH est facile, mais vous allez d’abord créer une exception non prise en charge qui sera enregistrée dans le journal ELMAH.

Appuyez sur Ctrl+F5 pour exécuter l’exemple d’application Wingtip Toys.
Pour écrire une exception non prise en charge dans le journal ELMAH, accédez dans votre navigateur à l’URL suivante (à l’aide de votre numéro de port) :
https://localhost:44300/NoPage.aspx La page d’erreur s’affiche.
Pour afficher le journal ELMAH, accédez dans votre navigateur à l’URL suivante (à l’aide de votre numéro de port) :
https://localhost:44300/elmah.axd

Résumé

Dans ce tutoriel, vous avez appris à gérer les erreurs au niveau de l’application, de la page et du code. Vous avez également appris à journaliser les erreurs gérées et non gérées pour une révision ultérieure. Vous avez ajouté l’utilitaire ELMAH pour fournir la journalisation et la notification des exceptions à votre application à l’aide de NuGet. En outre, vous avez appris l’importance des messages d’erreur sécurisés.

Conclusion de la série de tutoriels

Merci d’avoir suivi. J’espère que cet ensemble de tutoriels vous a aidé à vous familiariser avec ASP.NET Web Forms. Si vous avez besoin d’informations supplémentaires sur Web Forms fonctionnalités disponibles dans ASP.NET 4.5 et Visual Studio 2013, consultez ASP.NET et Web Tools pour Visual Studio 2013 notes de publication. Veillez également à jeter un coup d’œil au tutoriel mentionné dans la section Étapes suivantes et à essayer définitivement l’essai gratuit d’Azure.

Merci - Erik

Étapes suivantes

Pour en savoir plus sur le déploiement de votre application web sur Microsoft Azure, consultez Déployer une application ASP.NET Web Forms sécurisée avec appartenance, OAuth et SQL Database sur un site web Azure.

Version d’évaluation gratuite

Microsoft Azure - Essai gratuit
La publication de votre site web sur Microsoft Azure vous permet d’économiser du temps, de la maintenance et des dépenses. Il s’agit d’un processus rapide pour déployer votre application web sur Azure. Lorsque vous devez gérer et surveiller votre application web, Azure propose divers outils et services. Gérez les données, le trafic, l’identité, les sauvegardes, la messagerie, les médias et les performances dans Azure. Et tout cela est fourni dans une approche très économique.

Ressources supplémentaires

Journalisation des détails de l’erreur avec ASP.NET Health Monitoring
ELMAH

Remerciements

Je tiens à remercier les personnes suivantes qui ont apporté une contributions significative au contenu de cette série de tutoriels :

Alberto Poblacion, MVP & MCT, Espagne
Alex Thissen, Pays-Bas (twitter : @alexthissen)
André Tournier, États-Unis
Apurva Joshi, Microsoft
Bojan Vrhovnik, Slovénie
Bruno Sonnino, Brésil (twitter : @bsonnino)
Carlos dos Santos, Brésil
Dave Campbell, États-Unis (twitter : @windowsdevnews)
Jon Galloway, Microsoft (twitter : @jongalloway)
Michael Sharps, États-Unis (twitter : @mrsharps)
Mike Pope
Mitchel Sellers, États-Unis (twitter : @MitchelSellers)
Paul Cociuba, Microsoft
Paulo Morgado, Portugal
Pranav Rastogi, Microsoft
Tim Ammann, Microsoft
Tom Dykstra, Microsoft

Contributions de la communauté

Graham Mendick (@grahammendick)
Exemple de code lié à Visual Studio 2012 sur MSDN : Navigation Wingtip Toys
James Chaney (jchaney@agvance.net)
Exemple de code lié à Visual Studio 2012 sur MSDN : ASP.NET série de tutoriels Web Forms 4.5 dans Visual Basic
Andrielle Azevedo - Contributeur d’audience technique Microsoft (twitter : @driazevedo)
Traduction de Visual Studio 2012 : Iniciando com ASP.NET Web Forms 4.5 - Parte 1 - Introdução e Visão Geral

Partager via

Gestion des erreurs ASP.NET

Ce que vous allez apprendre :

Vue d’ensemble

Exception, classe

Hiérarchie d’héritage des exceptions

Hiérarchie de gestion des exceptions

Gestion des erreurs au niveau de l’application

Gestion des événements d’erreur au niveau de la page

Gestion des erreurs au niveau du code

Ajout de la prise en charge de la journalisation des erreurs

Ajout d’une page d’erreur

Affichage des messages d’erreur non gérés pour l’application

Mettre à jour la configuration

Exécution de l'application

Inclusion d’une exception à des fins de test

Exécution de l'application

Ajout de Application-Level gestion des erreurs

Exécution de l'application

Ajout de Page-Level gestion des erreurs

Exécution de l'application

Suppression de l’exception utilisée pour le test

Ajout Code-Level journalisation des erreurs

Inspection des informations de journalisation des erreurs

Messages d’erreur sécurisés

Utilisation d’ELMAH

Affichage du journal ELMAH

Résumé

Conclusion de la série de tutoriels

Étapes suivantes

Version d’évaluation gratuite

Ressources supplémentaires

Remerciements

Contributions de la communauté

Commentaires

Ressources supplémentaires