Tipicamente un’applicazione con interfaccia console o window la gestione globale dell’errore è piuttosto semplice.
Nel caso di interfaccia console:
static int Main(string[] args)
{
try
{
// Do application logic here
return 0;
}
catch (ParseCommandLineException pce)
{
Console.WriteLine("Usage error");
return 27;
}
catch (Exception e) {
Console.WriteLine(e);
return 42;
}
}
Nel caso di interfaccia WinForm:
[STAThread]
static void Main()
{
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
Application.Run(new Form1());
}
private void button1_Click(object sender, System.EventArgs e)
{
throw new Exception("Whoops");
}
private static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
MessageBox.Show(e.Exception.Message);
}
Nel caso invece di applicazione web verrebbe naturale ragionare nello stesso modo, scrivendo qualcosa come:
public class MyPage : System.Web.UI.Page
{
private string _errorMessage;
public string ErrorMessage { get { return _errorMessage; } }
protected new PageMaster Master { get { return (PageMaster)Page.Master; } }
protected void Page_Error(object sender, EventArgs e)
{
Exception objErr = Server.GetLastError();
EventLog.WriteEntry("MyWebform.aspx",err,EventLogEntryType.Error);
_errorMessage = objErr.Message;
Server.ClearError();
Server.Transfer(this.AppRelativeVirtualPath);
}
protected void Page_Load(object sender, EventArgs e)
{
/* Stampa messaggio di errore se presente */
if (this.PreviousPage != null)
{
MyPage previousPage = (MyPage)this.PreviousPage;
Master.ErrorLabel = previousPage.ErrorMessage;
}
}
}
Ma questo comporta il seguente problema:
Poiché la pagina deve poter essere completamente reinviata, perdo tutti i valori immessi dall’utente.
In altre parole, vorrei ottenere un PostBack con il messaggio di errore, ma il PostBack non può essere riprodotto.
Potremmo pensare diverse soluzioni:
- Si potrebbe provare a simulare il PostBack, forzando il salvataggio dei dati immessi in sessione per poi ricaricarli, ma .NET non lo permette
- Si potrebbe inviare una risposta HTTP personalizzata con il contenuto della pagina con associati i controlli immessi, ma non funziona
- Potremmo utilizzare AJAX per aggiornare solo la differenza di ciò che è cambiato. In questo caso funzionerebbe, ma:
- si obbligherebbe qualunque pulsante o qualunque metodo che potrebbe scatenare un’eccezione ad essere definito dentro un UpdatePanel, cosa sconsigliata per le prestazioni
- Invece di ricaricare la stessa pagina che ha causato l’errore potremmo eseguire una Transfer verso una pagina di errore a cui passiamo il messaggio di errore tramite CrossPagePostback. A questo punto potremmo fornire un pulsante “Torna indietro” che esegue il “Back” nella cronologia del browser. In questo caso funzionerebbe, ma:
- Dobbiamo “fidarci” della cache del browser
- Dobbiamo obbligare il browser a fare uso di javascript per tornare indietro
- In presenza di precedenti aggiornamenti AJAX il pulsante “Back” crea problemi: torna indietro solo del PostBack parziale. Potremmo utilizzare soluzioni articolate, come l’uso del server control History, ma non supportato nel framework 2.0
Dopo lunghe peripezie si può arrivare per ora ad una conclusione: bisogna abbandonare l’idea di gestire l’errore nel Page_Error. E allora come fare? Analizziamo quando possono avvenire gli errori nelle pagine ASP.NET:
- nell’inizializzazione delle pagine
- nelle PostBack, sincrone e asincrone
Per gestire l’errore “basterebbe” mettere un try/catch in tutte le parti di tutte le pagine. Per l’inizializzazione delle pagine si potrebbe pensare di gestire eventuali eccezioni in una classe Page customizzata che fa da padre per tutte le pagine che implementeremo. Potremmo quindi utilizzare il pattern Template come segue:
public abstract class MyPage : System.Web.UI.Page
{
private string _errorMessage;
public string ErrorMessage { get { return _errorMessage; } }
protected new PageMaster Master { get { return (PageMaster)Page.Master; } }
protected abstract void Specific_Page_Load(object sender, EventArgs e);
protected void Page_Load(object sender, EventArgs e)
{
/* Stampa messaggio di errore se presente */
if (this.PreviousPage != null)
{
MyPage previousPage = (MyPage)this.PreviousPage;
Master.ErrorLabel = previousPage.ErrorMessage;
}
try
{
Specific_Page_Load(sender, e);
}
catch(Exception objErr)
{
_errorMessage = objErr.Message;
}
}
}
public class LoginPage : MyPage
{
protected override void Specific_Page_Load(object sender, EventArgs e)
{
LoadControls(); // questo potrebbe causare un errore
}
}
Ma esiste comunque un problema:
Il client che utilizza MyPage si deve ricordare di non implementare mai il Page_Load, ma di implementare solo ed esclusivamente il Specific_Page_Load ereditato.
Vorremmo invece che l’utente non sia costretto a seguire un ordine mentale: il sistema deve gestire il controllo in modo trasparente. Per fare questo bisogna capire se esiste un metodo perno di tutti i Load, il cui fallimento comporta un fallimento di un qualunque eventuale load specializzato. Questo metodo esiste, ed è OnLoad, che richiama tutti i Page_Load (non gli OnLoad) creati seguendo il cosiddetto “Principio Di Hollywood” . Basta quindi sovrascrivere OnLoad in questo modo:
public abstract class MyPage : System.Web.UI.Page
{
protected new PageMaster Master { get { return (PageMaster)Page.Master; } }
protected override void OnLoad(EventArgs e)
{
try
{
base.OnLoad(e);
}
catch(Exception objErr)
{
Master.ErrorLabel = objErr.Message;
}
}
}
In modo analogo si può sovrascrivere il metodo perno di tutti i PostBack, RaisePostBackEvent.
Vogliamo infine perfezionare questa gestione rendendola generica e riutilizzabile.
Metto quindi a disposizione di chiunque fosse interessato la mia soluzione per la gestione globale delle eccezioni. Chi utilizzerà questa classe è sufficiente che tutte le pagine ereditino dalla vostra pagina customizzata, che a sua volta eredita dalla mia. La vostra pagina customizzata dovrà quindi implementare il metodo HandleError e il gioco è fatto.
using System;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;
using System.Drawing;
using System.Reflection;
namespace GenericException
{
/// <summary>
/// Inoltra tutte le richieste, ma gestisce l'eccezione e consente di visualizzarla
/// </summary>
public abstract class ExceptionManageablePage : System.Web.UI.Page
{
protected abstract void HandleError(Exception exception);
private delegate void MethodToTryCatchOneParam<Param1>(Param1 arg1);
private delegate void MethodToTryCatchTwoParam<Param1, Param2>(Param1 arg1, Param2 arg2);
private void ManageErrors<Param1>(MethodToTryCatchOneParam<Param1> method, Param1 arg1)
{
try
{
method(arg1);
}
catch (Exception ex)
{
HandleError(ex);
}
}
private void ManageErrors<Param1, Param2>(MethodToTryCatchTwoParam<Param1, Param2> method, Param1 arg1, Param2 arg2)
{
try
{
method(arg1, arg2);
}
catch (Exception ex)
{
HandleError(ex);
}
}
protected override void OnAbortTransaction(EventArgs e)
{
ManageErrors(base.OnAbortTransaction, e);
}
protected override void OnCommitTransaction(EventArgs e)
{
ManageErrors(base.OnCommitTransaction, e);
}
protected override void OnDataBinding(EventArgs e)
{
ManageErrors(base.OnDataBinding, e);
}
protected override void OnError(EventArgs e)
{
ManageErrors(base.OnError, e);
}
protected override void OnInit(EventArgs e)
{
ManageErrors(base.OnInit, e);
}
protected override void OnInitComplete(EventArgs e)
{
ManageErrors(base.OnInitComplete, e);
}
protected override void OnLoad(EventArgs e)
{
ManageErrors(base.OnLoad, e);
}
protected override void OnLoadComplete(EventArgs e)
{
ManageErrors(base.OnLoadComplete, e);
}
/// <summary>
/// Cattura eccezioni di qualunque postback, anche asincrono tramite Ajax. Ma in questo
/// ultimo caso anche l'HandleError deve supportare aggiornamenti asincroni (Label dentro un UpdatePanel)
/// </summary>
protected override void RaisePostBackEvent(IPostBackEventHandler sourceControl, string eventArgument)
{
ManageErrors(base.RaisePostBackEvent, sourceControl, eventArgument);
}
}
}
Bisogna infine dire che per i postback asincroni devo avere una gestione dell’errore che stampi un messaggio asincrono. Basta quindi inserire una label di errore con un UpdatePanel, o utilizzare una ModalPopupExtender. E ovviamente ogni consiglio è più che benvenuto!