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.
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.
- 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. - Inoltre l'utilizzo di entrambe le tecniche di intercettazione dell'errore (eventi
_Error, bloccotry 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.
