La gestione degli errori in ASP.NET (2/2)
di
John Kilgo
Data di pubblicazione: 07/01/2004
Voto della community: 4,11
(Votanti: 3)
Gestione degli errori a livello di Pagina
Due possibilità:
1. Reindirizzamento della pagina. 2. Uso dell'evento Error dell'oggetto Page Reindirizzamento della pagina Errori imprevedibili possono essere catturati con la proprietà ErrorPage dell'oggetto Page. Ciò consente la definizione di un URL redirection in caso di eccezioni non gestite. Un secondo step è tuttavia richiesto per abilitare tale trappola per gli errori, come di seguito:
<configuration> <system.web> <customErrors mode="On"> </customErrors> </system.web> </configuration> Così, piuttosto che la pagina stessa riportante l'errore, otterremmo il reindirizzamento a livello di pagina così specificato :
<%@ Page ErrorPage="http://www.cymru-web.net/GenericError.htm" %>
Un'utile opzione oltre ad abilitare/disabilitare l'attributo mode diCustomError è ‘RemoteOnly’ che, se specificato, reindirizza soltanto nel caso in cui il browser gira su un computer remoto. Ciò consente a chi accede al computer localmente di continuare a vedere gli errori realmente generati. Evento Error dell'oggetto Page L'oggetto Page ha un evento error che è generato quando una eccezione si verifica nella pagina. Non è lanciato se l'eccezione è gestita dal codice della pagina. La procedura rilevante è Page_Error che possiamo usare come illustrato nel seguente pezzo di codice:
Sub Page_Error(sender as Object, e as EventArgs)
dim PageException as string = Server.GetLastError().ToString() dim strBuild as new StringBuilder() strBuild.Append("Exception!") strBuild.Append(PageException) Response.Write(strBuild.ToString()) Context.ClearError() End Sub Come il reindirizzamento della pagina, questa soluzione consente di gestire errori inaspettati in una maniera più elegante. Torneremo a spiegare alcune delle classi usate nel frammento di codice quando vedremo lo scenario simile a livello di applicazione, nella sezione seguente. Gestione degli errori a livello di Applicazione
In realtà, è più probabile usare la gestione degli errori a livello di applicazione piuttosto che a livello di pagina. L'evento Application_Error di Global.asax esiste a questo scopo. Come è immaginabile, questo è lanciato quando si verifica un'eccezione nella corrispondente web application.
In Global.asax scriviamo il codice in risposta all'evento come segue:
Sub Application_Error(sender as Object, e as EventArgs)
'fare qualcosa End Sub Sfortunatamente l'argomento EventArgs di questo esempio non è abbastanza "informativo" ma ci sono strade alternative incluso un riferimento all'ultimo errore lanciato nell'applicazione. Questo può essere usato nel modo seguente:
Sub Application_Error(sender as Object, e as EventArgs)
dim LastException as string = Server.GetLastError().ToString() Context.ClearError() Response.Write(LastException) End Sub Notare che il metodo ClearError della classe Context cancella tutte le eccezioni dalla richiesta corrente - se non le cancellassimo, si verificherebbe il normale processo di eccezione e presentazione dell'errore. In alternativa, c'è la proprietà Error della classe HttpContext che restituisce un riferimento alla prima eccezione generata per la corrente HTTP request/response. Un esempio:
Sub Application_Error(sender as Object, e as EventArgs)
dim LastException as string = Context.Error.ToString() Context.ClearError() Response.Redirect("CustomErrors.aspx?Err=" & Server.UrlEncode(LastException)) End Sub Esso illustra un metodo per gestire gli errori a livello di applicazione -- il reindirizzamento ad una pagina di errore che può customizzare l'output dell'utente in base all'effettivo errore ricevuto. Infine, abbiamo anche la possibilità di implementare un reindirizzamento a livello di applicazione, attraverso la sezione customErrors di web.config già presentata, usando la proprietà defaultRedirect:
<configuration> <system.web> <customErrors mode="on" defaultRedirect="customerrors.aspx?err=Unspecified"> <error statusCode="404" redirect="customerrors.aspx?err=File+Not+Found"/> </customErrors> </system.web> </configuration> Notare che l'esempio mostra anche il reindirizzamento attraverso l'attributo error. L'enumeration HttpStatusCode contiene i possibili valori di statusCode. Questa è una lista troppo lunga per presentarla qui - vedere la documentazione SDK. Conclusioni
Spero che l'articolo abbia fornito una utile introduzione alle facilities per la gestione degli errori di ASP.NET. Spero inoltre che andrete avanti producendo codice migliore che faccia uso di queste facilities! In breve:
- Catturare i possibili errori in fase di design attraverso Option Excplicit e Option Strict. - Considerare in dettaglio i possibili errori che potrebbero verificarsi nella vostra applicazione - Usare il costrutto Try..Catch..Finally per catturare questi errori a livello di pagina o da qualsiasi altra parte - E' normalmente considerata una pratica poco raccomandabile usare le eccezioni per qualsiasi cosa, a meno che si tratti di problemi inusuali e sotto il vostro controllo (come la perdita di una connessione). Le eccezioni non dovrebbero essere usate per gesire gli errori di programmazione! - Usare la gestione degli errori a livello di applicazione ( e forse a livello di pagina) per catturare errori imprevedibili in maniera elegante. Riferimenti ASP.NET: Tips, Tutorial and Code Scott Mitchell et al. Sams Programming Visual Basic .NET Francesco Balena Microsoft Press .NET SDK Documentation 15 Seconds : Web Application Error Handling in ASP.NET http://15seconds.com/issue/030102.htm http://msdn.microsoft.com/msdnmag/issues/02/11/NETExceptions/default.aspx .NET Exceptions: Make the Transition from Traditional Visual Basic Error Handling to the Object-Oriented Model in .NET
Si ringrazia DotNetIt.com per la gentile concessione dell'articolo.
|