Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Gestire gli errori run-time con ASP.NET

Un corretto uso di Web.Config e Global.asax può essere vincente nella gestione delle eccezioni "impreviste" nell'esecuzione di applicazioni Web
Un corretto uso di Web.Config e Global.asax può essere vincente nella gestione delle eccezioni "impreviste" nell'esecuzione di applicazioni Web
Link copiato negli appunti

In questo articolo si parla della gestione degli errori nelle applicazioni ASP.NET. Fino alla versione ASP 3.0 si potevano gestire solamente gli errori di esecuzione, ma per gli errori HTTP (es: 404 Page Not Found) bisognava accedere alla configurazione di IIS ed indicare le pagine relative agli errori, operazione non sempre possibile perché normalmente consentita dai provider solo su server dedicati.

In ASP.NET, invece, si possono gestire sia gli errori di esecuzione sia gli errori HTTPle tipologie di errore senza accedere a configurazioni interne al Server.

Per gli errori HTTP possiamo avvalerci del file Web.Config e configurarlo in base al codice di
errore HTTP, per gli errori di esecuzione generati dall'Apllicazione possiamo utilizzare uno dei seguenti eventi: Global_Error, Application_Error, Page_Error.

In questo articolo modificheremo le impostazioni nei file:

  • Web.Config (File di configurazione nelle Applicazioni ASP.NET)
  • Global.asax (File di gestione degli Eventi dell'Applicazione)

Gestire gli errori HTTP con il file Web.Config

Gli errori HTTP sono errori generati durante l'esecuzione di un'applicazione, ma esterni ad essa. Un esempio puó essere una richiesta del Browser non valida, una pagina mancante, un errore del Server, e cosí via.

Modificando opportunamente il file Web.Config si può reindirizzare l'utente ad una pagina più consona di quella predefinita, offerta da IIS. Nel codice sottostante vengono gestiti i tre principali errori HTTP rimandando l'utente a pagine specifiche e gli altri errori reindirizzando l'utente in una pagina predefinita.

Listato 1. Frammento di codice del file "Web.Config"

<configuration>
<system.web>
<!-- pagina di redirect per l'errore comune -->
<customErrors mode="On" defaultRedirect="defaultError.aspx" />
<!-- pagina errore 401 -->
<error statusCode="401" redirect="NonAutorizzato.aspx" />
<!-- pagina errore 404 -->
<error statusCode="404" redirect="NonTrovato.aspx" />
<!-- pagina errore 500 -->
<error statusCode="500" redirect="ErroreServer.aspx" />

Analizziamo questo frammento. Il tag <customErrors> contiene l'attributo mode che può avere i seguenti valori:

  • On (gli errori persnalizzati vengono visualizzati sia dall'Utente sia sul Server),
  • RemoteOnly (solo gli utenti visualizzano gli errori personalizzati),
  • Off (gli errori HTTP vengono gestiti da IIS). Il tag error viene usato per gestire un singolo errore indicato nell'attributo statusCode.

Ecco il meccanismo col quale gestire errori HTTP agendo sul Web.Config presente nella cartella principale dell'Applicazione ASP.NET.

Errori di esecuzione e "Global.asax"

Gli errori di esecuzione (eccezioni non gestite) possono manifestarsi in ogni momento e spesso sono errori imprevedibili. Questo tipo di errore, se non correttamente gestito, può portare ad un'errata esecuzione della pagina che viene rimpiazzata da uno sgradevole messaggio di errore.

Figura 1. Un messaggio di errore
Errore di esecuzione

Le soluzioni che si possono adottare sono essenzialmente due: gestire le eccezioni "prevedibili" inserendo il codice sospetto in blocchi try e catch e intercettare gli errori non previsti usando negli eventi _Error forniti da ASP.NET

I metodi _Error sono esposti dalle classi Page e Application. La classe Page espone l'evento Page_Error che si manifesta quando viene rilasciata un'eccezione non gestita generata dalla pagina. La classe Application possiede l'evento Application_Error che viene intercettato nel file Global.asax e che ci consente di gestire tutti gli errori generati durante l'esecuzione e non esplicitamente gestiti dal codice.

Entrambe le classi possono usufruire del metodo GetLastError, presente nella classe Server. Questo metodo restituisce un oggetto di tipo Exception che
contiene l'eccezione generata dall'Applicazione.

In questo esempio intercettiamo il nostro errore nel file Global.asax, lo memorizziamo nella cache e passiamo la navigazione ad una pagina di errore, avendo cura di cancellare l'errore dalla lista tramite ClearError().

Listato 2. Pagina che genera errore

<script language="vb" runat="server">
Sub Page_Load (ByVal sender As Object, ByVal e As EventArgs)
'Generiamo un errore di prova
      Throw New ApplicationException("Errore di prova")
End Sub
</script>

Listato 3. Evento Application_Error presente nel file "Global.asax"

<script language="VB" runat="server">
Private Sub Application_Error (ByVal sender As Object, ByVal e As EventArgs)

  'reperiamo l'errore e lo assegnamo ad una variabile
  Dim ex As Exception = Server.GetLastError()
  Session("Error") = ex.Message()

  'eliminiamo l'errore generato
  Server.ClearError()

  'reindirizzamento alla pagina che gestisce gli errori
  Response.Redirect("Errore.aspx")

End Sub
</script>

Listato 4. Gestione dell'errore nella pagina "Errore.aspx"

<script language="VB" runat="server">
Private Sub Page_Load (ByVal sender As object, ByVal e As eventArgs)
  Response.Write("<p>Errore generato : " & Session("Errore").toString &"</p>")
  ...
</script>

Bisogna tener conto di due fattori prima di eliminare l'interecettazione dell'errore nel codice della pagina e passare tutto il lavoro al file Global.asax.

  1. Se l'errore viene gestito esclusivamente dall'evento Application_Error, il dettaglio di informazioni sarà inferiore e la capacità di gestire l'errore sarà più complessa.
  2. Inoltre l'utilizzo di entrambe le tecniche di intercettazione dell'errore (eventi _Error, blocco try catch), rende l'Applicazione robusta e stabile. Questo perchè saremmo in grado di gestire sia gli errori conosciuti, magari adottando una soluzione in esecuzione, sia gli altri imprevedibili errori, indirizzando l'utente verso una nuova pagina.


Ti consigliamo anche