Nello script #994 abbiamo visto come l'action filter HandleError possa essere utilizzato per mostrare una view personalizzata in caso di errore. Nel caso si vogliano mostrare view differenti a seconda della particolare eccezione sollevata dal controller, è possibile specificarle utilizzando la sintassi mostrata nell'esempio:

[HandleError(ExceptionType=typeof(DataException), View="DatabaseError")]
[HandleError(ExceptionType=typeof(SecurityException), View = "SecurityError")]
[HandleError]
public ActionResult Throw(int id)
{
    if (id == 1)
        throw new DataException();
    if (id == 2)
        throw new SecurityException();
    if (id == 3)
        throw new InvalidOperationException();
    
    return View();
}

In questo modo è possibile visualizzare una pagina apposita per DataException e SecurityException, mentre gli altri tipi di eccezione verranno gestiti normalmente tramite la view Error.

Quando si usano diversi gestori, però, bisogna porre grande attenzione ai vincoli di ereditarietà tra le exception. Il runtime valuta gli attributi secondo un ordine che non è predicibile e seleziona il primo il cui Type sia compatibile con l'eccezione sollevata. Nell'esempio precedente, allora, il rischio è che il gestore generico venga valutato prima di DataException e quindi, anche in corrispondenza di questo tipo di eccezione, venga utilizzata la view Error piuttosto che DatabaseError. E' allora opportuno forzare questo ordine di valutazione tramite la proprietà Order, in modo da dare priorità ai tipi più specifici:

[HandleError(ExceptionType=typeof(DataException), 
  View="DatabaseError", Order = 1)]
[HandleError(ExceptionType=typeof(SecurityException), 
  View="SecurityError", Order = 1)]
[HandleError(Order = 2)]
public ActionResult Throw(int id)
{
    if (id == 1)
        throw new DataException();
    if (id == 2)
        throw new SecurityException();
    if (id == 3)
        throw new InvalidOperationException();
    
    return View();
}