Gestione degli errori di ASP.NET

Articolo
06/16/2023

Scaricare il progetto di esempio Wingtip Toys (C#) o scaricare e-book (PDF)

Questa serie di esercitazioni illustra le nozioni di base per la creazione di un'applicazione Web Forms ASP.NET usando ASP.NET 4.5 e Microsoft Visual Studio Express 2013 per Web. Per questa serie di esercitazioni è disponibile un progetto di Visual Studio 2013 con codice sorgente C#.

In questa esercitazione si modificherà l'applicazione di esempio Wingtip Toys per includere la gestione degli errori e la registrazione degli errori. La gestione degli errori consentirà all'applicazione di gestire correttamente gli errori e visualizzare i messaggi di errore di conseguenza. La registrazione degli errori consentirà di trovare e correggere gli errori che si sono verificati. Questa esercitazione si basa sull'esercitazione precedente "Routing URL" e fa parte della serie di esercitazioni di Wingtip Toys.

Contenuto dell'esercitazione:

Come aggiungere la gestione degli errori globali alla configurazione dell'applicazione.
Come aggiungere la gestione degli errori a livello di applicazione, pagina e codice.
Come registrare gli errori per una revisione successiva.
Come visualizzare i messaggi di errore che non compromettono la sicurezza.
Come implementare i moduli di registrazione degli errori e la registrazione degli errori (ELMAH).

Panoramica

ASP.NET le applicazioni devono essere in grado di gestire gli errori che si verificano durante l'esecuzione in modo coerente. ASP.NET usa Common Language Runtime (CLR), che consente di notificare alle applicazioni errori in modo uniforme. Quando si verifica un errore, viene generata un'eccezione. Un'eccezione è un errore, una condizione o un comportamento imprevisto rilevato da un'applicazione.

In .NET Framework, un'eccezione è un oggetto che eredita dalla classe System.Exception. Le eccezioni vengono generate dalle aree di codice in cui si è verificato un problema. L'eccezione viene passata allo stack di chiamate a una posizione in cui l'applicazione fornisce il codice per gestire l'eccezione. Se l'applicazione non gestisce l'eccezione, il browser viene costretto a visualizzare i dettagli dell'errore.

Come procedura consigliata, gestire gli errori a livello di codice in Try//CatchFinally blocchi all'interno del codice. Provare a posizionare questi blocchi in modo che l'utente possa correggere i problemi nel contesto in cui si verificano. Se i blocchi di gestione degli errori sono troppo lontani da dove si è verificato l'errore, diventa più difficile fornire agli utenti le informazioni necessarie per risolvere il problema.

Classe Exception

La classe Exception è la classe base da cui ereditano le eccezioni. La maggior parte degli oggetti eccezione sono istanze di alcune classi derivate della classe Exception, ad esempio la SystemException classe , la IndexOutOfRangeException classe o la ArgumentNullException classe . La classe Exception dispone di proprietà, ad esempio la StackTrace proprietà , la InnerException proprietà e la Message proprietà , che forniscono informazioni specifiche sull'errore che si è verificato.

Gerarchia di ereditarietà delle eccezioni

Il runtime ha un set di base di eccezioni che derivano dalla classe generata dal SystemException runtime quando viene rilevata un'eccezione. La maggior parte delle classi che ereditano dalla classe Exception, ad esempio la IndexOutOfRangeException classe e la ArgumentNullException classe , non implementano membri aggiuntivi. Di conseguenza, le informazioni più importanti per un'eccezione sono disponibili nella gerarchia delle eccezioni, nel nome dell'eccezione e nelle informazioni contenute nell'eccezione.

Gerarchia di gestione delle eccezioni

In un'applicazione Web Forms ASP.NET le eccezioni possono essere gestite in base a una gerarchia di gestione specifica. È possibile gestire un'eccezione ai livelli seguenti:

Livello applicazione
Livello pagina
Livello di codice

Quando un'applicazione gestisce le eccezioni, è spesso possibile recuperare e visualizzare informazioni aggiuntive sull'eccezione ereditata dalla classe Exception. Oltre all'applicazione, alla pagina e al livello di codice, è anche possibile gestire le eccezioni a livello di modulo HTTP e usando un gestore personalizzato IIS.

Gestione degli errori a livello di applicazione

È possibile gestire gli errori predefiniti a livello di applicazione modificando la configurazione dell'applicazione o aggiungendo un Application_Error gestore nel file Global.asax dell'applicazione.

È possibile gestire gli errori predefiniti e gli errori HTTP aggiungendo una customErrors sezione al file diWeb.config . La customErrors sezione consente di specificare una pagina predefinita a cui gli utenti verranno reindirizzati quando si verifica un errore. Consente inoltre di specificare singole pagine per errori specifici del codice di stato.

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

Sfortunatamente, quando si usa la configurazione per reindirizzare l'utente a una pagina diversa, non sono presenti i dettagli dell'errore che si è verificato.

È tuttavia possibile intercettare gli errori che si verificano in qualsiasi punto dell'applicazione aggiungendo codice al Application_Error gestore nel file 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);
    }
}

Gestione degli eventi di errore a livello di pagina

Un gestore a livello di pagina restituisce l'utente alla pagina in cui si è verificato l'errore, ma poiché le istanze dei controlli non vengono mantenute, nella pagina non saranno più presenti elementi. Per fornire i dettagli dell'errore all'utente dell'applicazione, è necessario scrivere in modo specifico i dettagli dell'errore nella pagina.

In genere si usa un gestore errori a livello di pagina per registrare errori non gestiti o per portare l'utente a una pagina in grado di visualizzare informazioni utili.

Questo esempio di codice mostra un gestore per l'evento Error in una pagina Web ASP.NET. Questo gestore rileva tutte le eccezioni che non sono già gestite all'interno try/catch di blocchi nella pagina.

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

Dopo aver gestito un errore, è necessario cancellarlo chiamando il ClearError metodo dell'oggetto Server (HttpServerUtility classe ), altrimenti verrà visualizzato un errore che si è verificato in precedenza.

Gestione degli errori a livello di codice

L'istruzione try-catch è costituita da un blocco try seguito da una o più clausole catch, che specificano gestori per eccezioni diverse. Quando viene generata un'eccezione, Common Language Runtime (CLR) cerca l'istruzione catch che gestisce questa eccezione. Se il metodo attualmente in esecuzione non contiene un blocco catch, CLR esamina il metodo che ha chiamato il metodo corrente e così via, fino allo stack di chiamate. Se non viene trovato alcun blocco catch, CLR visualizza un messaggio di eccezione non gestito all'utente e arresta l'esecuzione del programma.

Nell'esempio di codice seguente viene illustrato un modo comune di usare try//catchfinally per gestire gli errori.

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

Nel codice precedente il blocco try contiene il codice che deve essere protetto da una possibile eccezione. Il blocco viene eseguito fino a quando non viene generata un'eccezione o il blocco viene completato correttamente. Se si verifica un'eccezione FileNotFoundException o un'eccezione IOException , l'esecuzione viene trasferita a una pagina diversa. Il codice contenuto nel blocco finally viene quindi eseguito, indipendentemente dal fatto che si sia verificato o meno un errore.

Aggiunta del supporto per la registrazione degli errori

Prima di aggiungere la gestione degli errori all'applicazione di esempio Wingtip Toys, si aggiungerà il supporto per la registrazione degli errori aggiungendo una ExceptionUtility classe alla cartella Logic . In questo modo, ogni volta che l'applicazione gestisce un errore, i dettagli dell'errore verranno aggiunti al file di log degli errori.

Fare clic con il pulsante destro del mouse sulla cartella Logica e quindi scegliere Aggiungi ->Nuovo elemento.
La finestra di dialogo Aggiungi nuovo elemento viene visualizzata.
Selezionare il gruppo Visual C# -Code templates (Modelli di Visual C# ->Code ) a sinistra. Selezionare quindi Classedall'elenco centrale e denominarla ExceptionUtility.cs.
Scegliere Aggiungi. Viene visualizzato il nuovo file di classe.

Sostituire il codice esistente con quello seguente:

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

Quando si verifica un'eccezione, l'eccezione può essere scritta in un file di log delle eccezioni chiamando il LogException metodo . Questo metodo accetta due parametri, l'oggetto eccezione e una stringa contenente i dettagli sull'origine dell'eccezione. Il log delle eccezioni viene scritto nel file ErrorLog.txt nella cartella App_Data .

Aggiunta di una pagina di errore

Nell'applicazione di esempio Wingtip Toys verrà usata una pagina per visualizzare gli errori. La pagina di errore è progettata per visualizzare un messaggio di errore sicuro agli utenti del sito. Tuttavia, se l'utente è uno sviluppatore che effettua una richiesta HTTP che viene servita localmente nel computer in cui si trova il codice, nella pagina di errore verranno visualizzati dettagli aggiuntivi sull'errore.

Fare clic con il pulsante destro del mouse sul nome del progetto (Wingtip Toys) in Esplora soluzioni e scegliere Aggiungi ->Nuovo elemento.
La finestra di dialogo Aggiungi nuovo elemento viene visualizzata.
Selezionare il gruppo Visual C# ->Web templates (Modelli Web) a sinistra. Nell'elenco centrale selezionare Web Form con pagina master e denominarlo ErrorPage.aspx.
Fare clic su Aggiungi.
Selezionare il file Site.Master come pagina master e quindi scegliere OK.

Sostituire il markup esistente con il codice seguente:

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

Sostituire il codice esistente del code-behind (ErrorPage.aspx.cs) in modo che venga visualizzato come segue:

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

Quando viene visualizzata la pagina di errore, viene eseguito il Page_Load gestore eventi. Page_Load Nel gestore viene determinato il percorso in cui l'errore è stato gestito per la prima volta. Quindi, l'ultimo errore che si è verificato è determinato dalla chiamata al GetLastError metodo dell'oggetto Server. Se l'eccezione non esiste più, viene creata un'eccezione generica. Quindi, se la richiesta HTTP è stata effettuata localmente, vengono visualizzati tutti i dettagli dell'errore. In questo caso, solo il computer locale che esegue l'applicazione Web visualizzerà questi dettagli dell'errore. Dopo la visualizzazione delle informazioni sull'errore, l'errore viene aggiunto al file di log e l'errore viene cancellato dal server.

Visualizzazione di messaggi di errore non gestiti per l'applicazione

Aggiungendo una customErrors sezione al file Web.config , è possibile gestire rapidamente semplici errori che si verificano in tutta l'applicazione. È anche possibile specificare come gestire gli errori in base al valore del codice di stato, ad esempio 404 - File non trovato.

Aggiornare la configurazione

Aggiornare la configurazione aggiungendo una customErrors sezione al file Web.config .

In Esplora soluzioni trovare e aprire il file Web.config nella radice dell'applicazione di esempio Wingtip Toys.

Aggiungere la customErrors sezione al file Web.config all'interno del <system.web> nodo come indicato di seguito:

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

Salvare il file Web.config.

La customErrors sezione specifica la modalità , che è impostata su "Sì". Specifica inoltre , defaultRedirectche indica all'applicazione quale pagina passare quando si verifica un errore. Inoltre, è stato aggiunto un elemento di errore specifico che specifica come gestire un errore 404 quando non viene trovata una pagina. Più avanti in questa esercitazione si aggiungeranno altre operazioni di gestione degli errori che acquisiranno i dettagli di un errore a livello di applicazione.

Esecuzione dell'applicazione

È ora possibile eseguire l'applicazione per visualizzare le route aggiornate.

Premere F5 per eseguire l'applicazione di esempio Wingtip Toys.
Il browser si apre e mostra la pagina Default.aspx .
Immettere l'URL seguente nel browser (assicurarsi di usare il numero di porta):
https://localhost:44300/NoPage.aspx
Esaminare errorPage.aspx visualizzato nel browser.

Quando si richiede la pagina NoPage.aspx , che non esiste, la pagina di errore mostrerà il messaggio di errore semplice e le informazioni dettagliate sull'errore, se sono disponibili dettagli aggiuntivi. Tuttavia, se l'utente ha richiesto una pagina inesistente da una posizione remota, la pagina di errore visualizzerebbe solo il messaggio di errore in rosso.

Inclusione di un'eccezione a scopo di test

Per verificare il funzionamento dell'applicazione quando si verifica un errore, è possibile creare deliberatamente condizioni di errore in ASP.NET. Nell'applicazione di esempio Wingtip Toys verrà generata un'eccezione di test quando la pagina predefinita viene caricata per vedere cosa accade.

Aprire il code-behind della pagina Default.aspx in Visual Studio.
Verrà visualizzata la pagina code-behind Default.aspx.cs .

Page_Load Nel gestore aggiungere il codice in modo che il gestore venga visualizzato come segue:

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

È possibile creare diversi tipi di eccezioni. Nel codice precedente si crea un oggetto InvalidOperationException quando viene caricata la pagina Default.aspx .

Esecuzione dell'applicazione

È possibile eseguire l'applicazione per vedere come l'applicazione gestisce l'eccezione.

Premere CTRL+F5 per eseguire l'applicazione di esempio Wingtip Toys.
L'applicazione genera l'eccezione InvalidOperationException.

Nota

È necessario premere CTRL+F5 per visualizzare la pagina senza interrompere il codice per visualizzare l'origine dell'errore in Visual Studio.
Esaminare errorPage.aspx visualizzato nel browser.

Come si può vedere nei dettagli dell'errore, l'eccezione è stata intrappolata dalla customError sezione nel file Web.config .

Aggiunta della gestione degli errori di Application-Level

Anziché intercettare l'eccezione usando la customErrors sezione nel file diWeb.config , in cui si ottengono poche informazioni sull'eccezione, è possibile intercettare l'errore a livello di applicazione e recuperare i dettagli dell'errore.

In Esplora soluzioni trovare e aprire il file Global.asax.cs.

Aggiungere un gestore Application_Error in modo che venga visualizzato come segue:

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

Quando si verifica un errore nell'applicazione, viene chiamato il Application_Error gestore. In questo gestore viene recuperata e esaminata l'ultima eccezione. Se l'eccezione non è stata gestita e l'eccezione contiene i dettagli dell'eccezione interna, ovvero non null, InnerException l'applicazione trasferisce l'esecuzione alla pagina di errore in cui vengono visualizzati i dettagli dell'eccezione.

Esecuzione dell'applicazione

È possibile eseguire l'applicazione per visualizzare i dettagli aggiuntivi dell'errore forniti gestendo l'eccezione a livello di applicazione.

Premere CTRL+F5 per eseguire l'applicazione di esempio Wingtip Toys.
L'applicazione genera l'eccezione InvalidOperationException .
Esaminare errorPage.aspx visualizzato nel browser.

Aggiunta della gestione degli errori di Page-Level

È possibile aggiungere la gestione degli errori a livello di pagina a una pagina usando l'aggiunta di un ErrorPage attributo alla @Page direttiva della pagina o aggiungendo un Page_Error gestore eventi al code-behind di una pagina. In questa sezione si aggiungerà un Page_Error gestore eventi che trasferisce l'esecuzione alla pagina ErrorPage.aspx .

In Esplora soluzioni trovare e aprire il file Default.aspx.cs.

Aggiungere un Page_Error gestore in modo che il code-behind venga visualizzato come segue:

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

Quando si verifica un errore nella pagina, viene chiamato il Page_Error gestore eventi. In questo gestore viene recuperata e esaminata l'ultima eccezione. Se si verifica un InvalidOperationException oggetto , il gestore eventi trasferisce l'esecuzione Page_Error alla pagina di errore in cui vengono visualizzati i dettagli dell'eccezione.

Esecuzione dell'applicazione

È ora possibile eseguire l'applicazione per visualizzare le route aggiornate.

Premere CTRL+F5 per eseguire l'applicazione di esempio Wingtip Toys.
L'applicazione genera l'eccezione InvalidOperationException .
Esaminare errorPage.aspx visualizzato nel browser.
Chiudere la finestra del browser.

Rimozione dell'eccezione usata per il test

Per consentire all'applicazione di esempio Wingtip Toys di funzionare senza generare l'eccezione aggiunta in precedenza in questa esercitazione, rimuovere l'eccezione.

Aprire il code-behind della pagina Default.aspx .
Page_Load Nel gestore rimuovere il codice che genera l'eccezione in modo che il gestore venga visualizzato come segue:
```
protected void Page_Load(object sender, EventArgs e)
{

}
```

Aggiunta della registrazione degli errori di Code-Level

Come accennato in precedenza in questa esercitazione, è possibile aggiungere istruzioni try/catch per tentare di eseguire una sezione di codice e gestire il primo errore che si verifica. In questo esempio verranno scritti solo i dettagli dell'errore nel file di log degli errori in modo che l'errore possa essere esaminato in un secondo momento.

In Esplora soluzioni, nella cartella Logic trovare e aprire il file PayPalFunctions.cs.

Aggiornare il HttpCall metodo in modo che il codice venga visualizzato come segue:

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

Il codice precedente chiama il LogException metodo contenuto nella ExceptionUtility classe . In questa esercitazione è stato aggiunto il file di classe ExceptionUtility.cs alla cartella Logic . Il metodo LogException accetta due parametri. Il primo parametro è l'oggetto eccezione. Il secondo parametro è una stringa usata per riconoscere l'origine dell'errore.

Controllo delle informazioni di registrazione degli errori

Come accennato in precedenza, è possibile usare il log degli errori per determinare quali errori nell'applicazione devono essere corretti per primi. Naturalmente, verranno registrati solo gli errori che sono stati intrappolati e scritti nel log degli errori.

In Esplora soluzioni trovare e aprire il file ErrorLog.txt nella cartella App_Data.
Potrebbe essere necessario selezionare l'opzione "Mostra tutti i file" o l'opzione "Aggiorna" nella parte superiore di Esplora soluzioni per visualizzare il file ErrorLog.txt.
Esaminare il log degli errori visualizzato in Visual Studio:

Messaggi di errore sicuri

È importante notare che quando l'applicazione visualizza i messaggi di errore, non deve fornire informazioni che un utente malintenzionato potrebbe trovare utile per attaccare l'applicazione. Ad esempio, se l'applicazione tenta in modo non riuscito di scrivere in un database, non deve visualizzare un messaggio di errore che include il nome utente in uso. Per questo motivo, all'utente viene visualizzato un messaggio di errore generico in rosso. Tutti i dettagli aggiuntivi sull'errore vengono visualizzati solo allo sviluppatore nel computer locale.

Uso di ELMAH

ELMAH (Error Logging Modules and Handlers) è una funzionalità di registrazione degli errori che si collega all'applicazione ASP.NET come pacchetto NuGet. ELMAH offre le funzionalità seguenti:

Registrazione di eccezioni non gestite.
Pagina Web per visualizzare l'intero log delle eccezioni non gestite codificate.
Pagina Web per visualizzare i dettagli completi di ogni eccezione registrata.
Notifica tramite posta elettronica di ogni errore al momento in cui si verifica.
Feed RSS degli ultimi 15 errori del log.

Prima di poter usare ELMAH, è necessario installarlo. È facile usare il programma di installazione del pacchetto NuGet . Come accennato in precedenza in questa serie di esercitazioni, NuGet è un'estensione di Visual Studio che semplifica l'installazione e l'aggiornamento di librerie e strumenti open source in Visual Studio.

In Visual Studio scegliere Gestione pacchetti>NuGet per la soluzione dal menu Strumenti.
La finestra di dialogo Gestisci pacchetti NuGet viene visualizzata in Visual Studio.
Nella finestra di dialogo Gestisci pacchetti NuGet espandere Online a sinistra e quindi selezionare nuget.org. Trovare e installare quindi il pacchetto ELMAH dall'elenco dei pacchetti disponibili online.
Per scaricare il pacchetto, sarà necessario disporre di una connessione Internet.
Nella finestra di dialogo Seleziona progetti verificare che sia selezionata la selezione WingtipToys e quindi fare clic su OK.
Fare clic su Chiudi nella finestra di dialogo Gestisci pacchetti NuGet , se necessario.
Se Visual Studio richiede di ricaricare i file aperti, selezionare "Sì a tutti".
Il pacchetto ELMAH aggiunge voci per se stesso nel file Web.config alla radice del progetto. Se Visual Studio chiede se si desidera ricaricare il file diWeb.config modificato, fare clic su Sì.

ELMAH è ora pronto per archiviare eventuali errori non gestiti che si verificano.

Visualizzazione del log ELMAH

La visualizzazione del log ELMAH è semplice, ma prima si creerà un'eccezione non gestita che verrà registrata nel log ELMAH.

Premere CTRL+F5 per eseguire l'applicazione di esempio Wingtip Toys.
Per scrivere un'eccezione non gestita nel log ELMAH, passare nel browser all'URL seguente (usando il numero di porta):
https://localhost:44300/NoPage.aspx Verrà visualizzata la pagina di errore.
Per visualizzare il log ELMAH, passare nel browser all'URL seguente (usando il numero di porta):
https://localhost:44300/elmah.axd

Riepilogo

In questa esercitazione si è appreso come gestire gli errori a livello di applicazione, a livello di pagina e a livello di codice. Si è anche appreso come registrare gli errori gestiti e non gestiti per una revisione successiva. È stata aggiunta l'utilità ELMAH per fornire la registrazione delle eccezioni e la notifica all'applicazione usando NuGet. Inoltre, si è appreso l'importanza dei messaggi di errore sicuri.

Conclusione della serie di esercitazioni

Grazie per aver seguito. Spero che questo set di esercitazioni ti abbia aiutato a acquisire familiarità con Web Forms ASP.NET. Per altre informazioni sulle funzionalità di Web Forms disponibili in ASP.NET 4.5 e Visual Studio 2013, vedere ASP.NET and Web Tools per Visual Studio 2013 note sulla versione. Assicurarsi anche di esaminare l'esercitazione descritta nella sezione Passaggi successivi e provare la versione di valutazione gratuita di Azure.

Grazie - Erik

Passaggi successivi

Altre informazioni sulla distribuzione dell'applicazione Web in Microsoft Azure, vedere Distribuire un'app di Web Forms ASP.NET sicura con appartenenza, OAuth e database SQL in un sito Web di Azure.

Versione di valutazione gratuita

Microsoft Azure - Versione di valutazione gratuita
La pubblicazione del sito Web in Microsoft Azure consente di risparmiare tempo, manutenzione e spese. È un processo rapido per distribuire l'app Web in Azure. Quando è necessario gestire e monitorare l'app Web, Azure offre un'ampia gamma di strumenti e servizi. Gestire dati, traffico, identità, backup, messaggistica, supporti e prestazioni in Azure. E tutto questo viene fornito in un approccio molto conveniente.

Risorse aggiuntive

Registrazione dei dettagli degli errori con monitoraggio dell'integrità di ASP.NET
ELMAH

Riconoscimenti

Vorrei ringraziare le persone seguenti che hanno apportato contributi significativi al contenuto di questa serie di esercitazioni:

Alberto Poblacion, MVP & MCT, Spagna
Alex Thissen, Paesi Bassi (twitter: @alexthissen)
Andre Tournier, Stati Uniti
Apurva Joshi, Microsoft
Bojan Vrhovnik, Slovenia
Bruno Sonnino, Brasile (twitter: @bsonnino)
Carlos dos Santos, Brasile
Dave Campbell, Stati Uniti (twitter: @windowsdevnews)
Jon Galloway, Microsoft (twitter: @jongalloway)
Michael Sharps, Stati Uniti (twitter: @mrsharps)
Mike Pope
Mitchel Seller, Stati Uniti (twitter: @MitchelSellers)
Paul Cociuba, Microsoft
Paulo Morgado, Portogallo
Pranav Rastogi, Microsoft
Tim Ammann, Microsoft
Tom Dykstra, Microsoft

Contributi della community

Graham Mendick (@grahammendick)
Esempio di codice correlato a Visual Studio 2012 su MSDN: Navigation Wingtip Toys
James Chaney (jchaney@agvance.net)
Esempio di codice correlato a Visual Studio 2012 in MSDN: serie di esercitazioni ASP.NET 4.5 Web Forms in Visual Basic
Andrielle Azevedo - Microsoft Technical Audience Contributor (twitter: @driazevedo)
Traduzione di Visual Studio 2012: Iniciando com Web Forms ASP.NET 4.5 - Parte 1 - Introdução e Visão Geral

Indietro

Condividi tramite

Gestione degli errori di ASP.NET

Contenuto dell'esercitazione:

Panoramica

Classe Exception

Gerarchia di ereditarietà delle eccezioni

Gerarchia di gestione delle eccezioni

Gestione degli errori a livello di applicazione

Gestione degli eventi di errore a livello di pagina

Gestione degli errori a livello di codice

Aggiunta del supporto per la registrazione degli errori

Aggiunta di una pagina di errore

Visualizzazione di messaggi di errore non gestiti per l'applicazione

Aggiornare la configurazione

Esecuzione dell'applicazione

Inclusione di un'eccezione a scopo di test

Esecuzione dell'applicazione

Aggiunta della gestione degli errori di Application-Level

Esecuzione dell'applicazione

Aggiunta della gestione degli errori di Page-Level

Esecuzione dell'applicazione

Rimozione dell'eccezione usata per il test

Aggiunta della registrazione degli errori di Code-Level

Controllo delle informazioni di registrazione degli errori

Messaggi di errore sicuri

Uso di ELMAH

Visualizzazione del log ELMAH

Riepilogo

Conclusione della serie di esercitazioni

Passaggi successivi

Versione di valutazione gratuita

Risorse aggiuntive

Riconoscimenti

Contributi della community

Commenti e suggerimenti

Risorse aggiuntive