Quali sono le linee guida definitive per la gestione degli errori personalizzata in ASP.NET MVC 3?

Condividerò il modo in cui ho finito, facendo parte della domanda originale.

Innanzitutto, i problemi che ho riscontrato:

1. Con customErrors su (vale a dire in produzione) l'attributo globale HandleError inceppa le eccezioni e rende la vista errori, ma non puoi loggarlo con uno strumento addon come elmah, dato che elmah non lo vede mai. Potresti collegarlo alla tua vista, suppongo, ma è una visione che sembra sbagliata. L'attributo HandleError globale appare nuovo nel modello di progetto MVC 3 RTM Visual Studio.

2. CustomErrors con URL per endpoint MVC restituisce 302 codici di stato. Esiste la proprietà redirectmode, ma non è possibile associare gli URL mvc in customErrors e utilizzare la modalità ResponseRewrite. ( link )

3. Evitare completamente CustomErrors e gestire tutto ciò che è personalizzato nella tua app porta a un sacco di complessità, IMO. (Iloved this: link , ma non era giusto per il nostro progetto)

La mia soluzione

Ho rimosso completamente MVC dall'equazione. Ho rimosso HandleErrorAttribute filtro globale in global.asax e mi sono concentrato interamente sulla configurazione di CustomErrors, spostandola per utilizzare i reindirizzamenti WebForm e passare a redirectmode a ResponseRewrite per evitare i codici di risposta HTTP 302.

<customErrors mode="On" defaultRedirect="/Error.aspx" redirectMode="ResponseRewrite">
  <error statusCode="404" redirect="/NotFound.aspx" />
</customErrors>

Quindi, in NotFound.aspx page_load event, imposta Response.StatusCode su 404 e in Error.aspx setta il codice 500.

Risultati:

Gli obiettivi per entrambi sono stati raggiunti con i log di Elmah, la pagina di errore descrittivo e il codice di stato con una riga di codice sui code-behind. Non stiamo facendo il "MVC Way" come fa la soluzione precedente, ma sono d'accordo con questo se si tratta di due linee di codice.

Penso che MVC, ASP e il tuo framework di gestione delle eccezioni / registrazione preferito siano in grado di gestire i tuoi obiettivi in modo abbastanza preciso. ELMAH e Enterprise Library forniscono sia la gestione delle eccezioni che la gestione delle eccezioni, quindi scegli il tuo preferito. Non ho intenzione di addentrarmi nei pro e contro di ciascuno.

NOTA: non puoi visualizzare una pagina di errore amichevole E restituire un HTTP 404 o 500 come suggerisce la tua domanda. Quando si restituisce una pagina di errore descrittivo, il codice HTTP restituito al browser sarà 302. Si tratta di un reindirizzamento alla pagina di errore descrittivo.

Pagine di errore descrittive

Sembra che tu possa raggiungere i tuoi obiettivi con le buone impostazioni web.config che fanno parte di ASP.net da un po 'di tempo. Si menziona la visualizzazione delle informazioni di debug in dev e la visualizzazione di pagine amichevoli in produzione. Puoi usare la sezione degli errori personalizzati di web.config per questo (Imposta CustomErrors="Off" per mostrare le informazioni di debug). Presumo che tu abbia familiarità con l'attributo CustomErrors, se non leggi questo:

link

Se è necessaria una maggiore granularità del controllo su quali visualizzazioni di errore vengono visualizzate, utilizzare l'attributo HandleError di MVC. In questo modo puoi scegliere diverse visualizzazioni di errore per ogni Azione / Controller.

link

Registrazione delle eccezioni

Sembra che tu voglia rispondere a tutte le tue eccezioni allo stesso modo ("registra gli errori e mandali via email all'amministratore in produzione"). In tal caso, l'opzione più semplice è aggiungere il codice a

Application_Error (oggetto mittente, EventArgs e)

nel tuo global.asax. È qui che puoi passare al framework di registrazione prescelto.

Se desideri un maggiore controllo sulla registrazione / gestione delle eccezioni, puoi eseguire la sottoclasse di HandleErrorAttribute e override

OnException(System.Web.Mvc.ExceptionContext filterContext)

questo è un altro posto in cui puoi passare al framework di registrazione prescelto.

link

Questo ti dà più controllo della tecnica Application_Error sopra menzionata.

In generale MVC offre una granularità di controllo su come gestire gli errori. Se non hai bisogno di questo controllo, puoi ricorrere ai sistemi ASP.net per fare cose come la definizione di pagine di errore sul tuo web.config.