Visualizzazione di una pagina di errore personalizzata (C#)

di Scott Mitchell

Cosa viene visualizzato dall'utente quando si verifica un errore di runtime in un'applicazione Web ASP.NET? La risposta dipende dal modo in cui la configurazione customErrors> del <sito Web. Per impostazione predefinita, agli utenti viene visualizzata una schermata gialla antisightly che indica che si è verificato un errore di runtime. Questa esercitazione illustra come personalizzare queste impostazioni per visualizzare una pagina di errore personalizzata esteticamente piacevole che corrisponde all'aspetto e all'aspetto del sito.

Introduzione

In un mondo perfetto non ci sarebbero errori di run-time. I programmatori scriverebbero codice con un bug e con una convalida affidabile dell'input utente e risorse esterne come server di database e server di posta elettronica non sarebbero mai offline. Naturalmente, in realtà gli errori sono inevitabili. Le classi in .NET Framework segnalano un errore generando un'eccezione. Ad esempio, la chiamata al metodo Open di un oggetto SqlConnection stabilisce una connessione al database specificato da una stringa di connessione. Tuttavia, se il database è inattivo o se le credenziali nella stringa di connessione non sono valide, il metodo Open genera un'eccezione SqlException. Le eccezioni possono essere gestite tramite l'uso di try/catch/finally blocchi. Se il codice all'interno di un try blocco genera un'eccezione, il controllo viene trasferito al blocco catch appropriato in cui lo sviluppatore può tentare di eseguire il ripristino dall'errore. Se non è presente alcun blocco catch corrispondente o se il codice che ha generato l'eccezione non si trova in un blocco try, l'eccezione percola fino allo stack di chiamate nella ricerca di try/catch/finally blocchi.

Se l'eccezione raggiunge il runtime di ASP.NET senza essere gestito, viene generato l'evento HttpApplicationdella Error classe e viene visualizzata la pagina di errore configurata. Per impostazione predefinita, ASP.NET visualizza una pagina di errore denominata YSOD ( Schermata gialla della morte ). Esistono due versioni di YSOD: una mostra i dettagli dell'eccezione, un'analisi dello stack e altre informazioni utili per gli sviluppatori che eseguono il debug dell'applicazione (vedere la figura 1); l'altro indica semplicemente che si è verificato un errore di run-time (vedere la figura 2).

I dettagli dell'eccezione YSOD sono molto utili per gli sviluppatori che esevono il debug dell'applicazione, ma la visualizzazione di un YSOD per gli utenti finali è molto utile e non professionale. Gli utenti finali devono invece essere visualizzati in una pagina di errore che mantiene l'aspetto del sito con prosa più intuitiva che descrive la situazione. La buona notizia è che la creazione di una pagina di errore personalizzata è piuttosto semplice. Questa esercitazione inizia con un'occhiata ad ASP. Pagine di errore diverse di NET. Viene quindi illustrato come configurare l'applicazione Web per mostrare agli utenti una pagina di errore personalizzata in caso di errore.

Esame dei tre tipi di pagine di errore

Quando si verifica un'eccezione non gestita in un'applicazione ASP.NET viene visualizzata una di tre tipi di pagine di errore:

• Pagina dell'errore Di errore nella schermata gialla dell'eccezione,
• Pagina Errore di runtime Giallo schermata di errore di morte o
• Pagina di errore personalizzata

Gli sviluppatori della pagina degli errori hanno familiarità con i dettagli dell'eccezione YSOD. Per impostazione predefinita, questa pagina viene visualizzata agli utenti che visitano localmente e pertanto è la pagina visualizzata quando si verifica un errore durante il test del sito nell'ambiente di sviluppo. Come suggerisce il nome, l'YSOD dettagli eccezione fornisce informazioni dettagliate sull'eccezione, ovvero il tipo, il messaggio e l'analisi dello stack. Inoltre, se l'eccezione è stata generata dal codice nella classe code-behind della pagina di ASP.NET e se l'applicazione è configurata per il debug, l'eccezione Dettagli YSOD mostrerà anche questa riga di codice (e alcune righe di codice sopra e sotto di esso).

La figura 1 mostra la pagina Dettagli eccezione YSOD. Prendere nota dell'URL nella finestra dell'indirizzo del browser: http://localhost:62275/Genre.aspx?ID=foo. Si ricordi che la Genre.aspx pagina elenca le recensioni del libro in un particolare genere. Richiede che il GenreId valore (a uniqueidentifier) venga passato tramite la stringa di query. Ad esempio, l'URL appropriato per visualizzare le revisioni fittizie è Genre.aspx?ID=7683ab5d-4589-4f03-a139-1c26044d0146. Se un valore nonuniqueidentifier viene passato tramite la stringa di query ,ad esempio "foo", viene generata un'eccezione.

Si notino le informazioni sulle eccezioni presentate nella figura 1. Il messaggio di eccezione "Conversione non riuscita durante la conversione da una stringa di caratteri a uniqueidentifier" è presente nella parte superiore della pagina. Viene elencato anche il tipo di eccezione , System.Data.SqlClient.SqlException. C'è anche l'analisi dello stack.

Figura 1: I dettagli dell'eccezione YSOD includono informazioni sull'eccezione
(Fare clic per visualizzare l'immagine a dimensione intera)

L'altro tipo di YSOD è l'errore di runtime YSOD ed è illustrato nella figura 2. L'errore di runtime YSOD informa il visitatore che si è verificato un errore di runtime, ma non include informazioni sull'eccezione generata. Tuttavia, fornisce istruzioni su come rendere visualizzabili i dettagli dell'errore modificando il Web.config file, che fa parte di ciò che rende questo aspetto YSOD non professionale.

Per impostazione predefinita, l'errore di runtime YSOD viene visualizzato agli utenti che visitano in remoto (tramite http://www.yoursite.com), come evidenziato dall'URL nella barra degli indirizzi del browser nella figura 2: http://httpruntime.web703.discountasp.net/Genre.aspx?ID=foo. Le due diverse schermate YSOD esistono perché gli sviluppatori sono interessati a conoscere i dettagli dell'errore, ma tali informazioni non devono essere visualizzate in un sito live perché potrebbero rivelare potenziali vulnerabilità di sicurezza o altre informazioni riservate a chiunque visiti il sito.

Figura 2: L'errore di runtime YSOD non include dettagli sugli errori
(Fare clic per visualizzare l'immagine a dimensione intera)

Il terzo tipo di pagina di errore è la pagina di errore personalizzata, ovvero una pagina Web creata. Il vantaggio di una pagina di errore personalizzata è che si ha il controllo completo sulle informazioni visualizzate all'utente insieme all'aspetto della pagina; la pagina di errore personalizzata può usare la stessa pagina master e gli stili delle altre pagine. La sezione "Utilizzo di una pagina di errore personalizzata" illustra la creazione di una pagina di errore personalizzata e la configurazione per la visualizzazione in caso di eccezione non gestita. La figura 3 offre un picco di questa pagina di errore personalizzata. Come si può notare, l'aspetto della pagina di errore è molto più professionale di una delle schermate gialle della morte mostrate nelle figure 1 e 2.

Figura 3: Una pagina di errore personalizzata offre un aspetto più personalizzato
(Fare clic per visualizzare l'immagine a dimensione intera)

Esaminare la barra degli indirizzi del browser nella figura 3. Si noti che la barra degli indirizzi mostra l'URL della pagina di errore personalizzata (/ErrorPages/Oops.aspx). Nelle figure 1 e 2 le schermate gialle della morte sono visualizzate nella stessa pagina da cui ha avuto origine l'errore (Genre.aspx). La pagina di errore personalizzata viene passata all'URL della pagina in cui si è verificato l'errore tramite il aspxerrorpath parametro querystring.

Configurazione della pagina di errore visualizzata

Quale delle tre pagine di errore possibili viene visualizzata è basata su due variabili:

• Informazioni di configurazione nella <customErrors> sezione e
• Indica se l'utente visita il sito in locale o in remoto.

La <customErrors> sezione in Web.config ha due attributi che influiscono sulla pagina di errore visualizzata: defaultRedirect e mode. L'attributo defaultRedirect è facoltativo. Se specificato, specifica l'URL della pagina di errore personalizzata e indica che la pagina di errore personalizzata deve essere visualizzata anziché l'errore di runtime YSOD. L'attributo mode è obbligatorio e accetta uno dei tre valori: On, Offo RemoteOnly. Questi valori hanno il comportamento seguente:

• On - indica che la pagina di errore personalizzata o l'errore di runtime YSOD viene visualizzata a tutti i visitatori, indipendentemente dal fatto che siano locali o remoti.
• Off - specifica che i dettagli eccezione YSOD vengono visualizzati a tutti i visitatori, indipendentemente dal fatto che siano locali o remoti.
• RemoteOnly - indica che la pagina di errore personalizzata o l'errore di runtime YSOD viene visualizzata ai visitatori remoti, mentre i dettagli dell'eccezione YSOD vengono visualizzati ai visitatori locali.

A meno che non si specifichi diversamente, ASP.NET agisce come se fosse stato impostato l'attributo mode su RemoteOnly e non fosse stato specificato un defaultRedirect valore. In altre parole, il comportamento predefinito è che i dettagli eccezione YSOD vengono visualizzati ai visitatori locali mentre l'errore di runtime YSOD viene visualizzato ai visitatori remoti. È possibile eseguire l'override di questo comportamento predefinito aggiungendo una <customErrors> sezione all'applicazione Web Web.config file.

Uso di una pagina di errore personalizzata

Ogni applicazione Web deve avere una pagina di errore personalizzata. Offre un'alternativa più professionale all'errore di runtime YSOD, è facile creare e configurare l'applicazione in modo da usare la pagina di errore personalizzata richiede solo alcuni istanti. Il primo passaggio consiste nel creare la pagina di errore personalizzata. È stata aggiunta una nuova cartella all'applicazione Book Reviews denominata ErrorPages e aggiunta a tale nuova pagina ASP.NET denominata Oops.aspx. Fare in modo che la pagina usi la stessa pagina master del resto delle pagine del sito in modo che erediti automaticamente lo stesso aspetto.

Figura 4: Creare una pagina di errore personalizzata

Successivamente, dedicare alcuni minuti alla creazione del contenuto per la pagina di errore. Ho creato una pagina di errore personalizzata piuttosto semplice con un messaggio che indica che si è verificato un errore imprevisto e un collegamento alla home page del sito.

Figura 5: Progettare la pagina di errore personalizzata
(Fare clic per visualizzare l'immagine a dimensione intera)

Al termine della pagina di errore, configurare l'applicazione Web in modo da usare la pagina di errore personalizzata al posto dell'errore di runtime YSOD. A tale scopo, specificare l'URL della pagina di errore nell'attributo <customErrors> della defaultRedirect sezione. Aggiungere il markup seguente al file dell'applicazione Web.config :

<configuration>
    ...

    <system.web>
        <customErrors mode="RemoteOnly"
                      defaultRedirect="~/ErrorPages/Oops.aspx" />

        ...
    </system.web>
</configuration>

Il markup precedente configura l'applicazione in modo che mostri i dettagli dell'eccezione YSOD agli utenti che visitano localmente, usando la pagina di errore personalizzata Oops.aspx per gli utenti che visitano in remoto. Per verificarlo in azione, distribuire il sito Web nell'ambiente di produzione e quindi visitare la pagina Genre.aspx nel sito live con un valore querystring non valido. Verrà visualizzata la pagina di errore personalizzata (fare riferimento alla figura 3).

Per verificare che la pagina di errore personalizzata venga visualizzata solo agli utenti remoti, visitare la Genre.aspx pagina con una stringa di query non valida dall'ambiente di sviluppo. Dovrebbero essere visualizzati i dettagli dell'eccezione YSOD (fare riferimento alla figura 1). L'impostazione RemoteOnly garantisce che gli utenti che visitano il sito nell'ambiente di produzione visualizzino la pagina di errore personalizzata mentre gli sviluppatori che lavorano in locale continuano a visualizzare i dettagli dell'eccezione.

Notifica agli sviluppatori e dettagli degli errori di registrazione

Gli errori che si verificano nell'ambiente di sviluppo sono stati causati dallo sviluppatore seduto nel computer. Viene visualizzata l'informazione dell'eccezione in Dettagli eccezione YSOD e sa quali passaggi stava eseguendo quando si è verificato l'errore. Tuttavia, quando si verifica un errore nell'ambiente di produzione, lo sviluppatore non ha alcuna conoscenza che si è verificato un errore a meno che l'utente finale che visita il sito non abbia il tempo necessario per segnalare l'errore. E anche se l'utente esce dal suo modo di avvisare il team di sviluppo che si è verificato un errore, senza conoscere il tipo di eccezione, il messaggio e l'analisi dello stack può essere difficile diagnosticare la causa dell'errore, ma non risolverlo.

Per questi motivi è fondamentale che qualsiasi errore nell'ambiente di produzione venga registrato in un archivio permanente (ad esempio un database) e che gli sviluppatori vengano avvisati di questo errore. La pagina di errore personalizzata può sembrare una buona posizione per eseguire questa registrazione e notifica. Sfortunatamente, la pagina di errore personalizzata non ha accesso ai dettagli dell'errore e pertanto non può essere usata per registrare queste informazioni. La buona notizia è che esistono diversi modi per intercettare i dettagli dell'errore e registrarli e le tre esercitazioni successive esplorano questo argomento in modo più dettagliato.

Uso di pagine di errore personalizzate diverse per diversi stati di errore HTTP

Quando viene generata un'eccezione da una pagina di ASP.NET e non viene gestita, l'eccezione percola fino al runtime di ASP.NET, che visualizza la pagina di errore configurata. Se una richiesta viene inviata al motore di ASP.NET ma non può essere elaborata per qualche motivo, ad esempio il file richiesto non viene trovato o le autorizzazioni di lettura sono state disabilitate per il file, il motore di ASP.NET genera un oggetto HttpException. Questa eccezione, ad esempio le eccezioni generate da ASP.NET pagine, viene visualizzata fino al runtime, causando la visualizzazione della pagina di errore appropriata.

Ciò significa che per l'applicazione Web nell'ambiente di produzione è che se un utente richiede una pagina non trovata, verrà visualizzata la pagina di errore personalizzata. La figura 6 mostra un esempio di questo tipo. Poiché la richiesta è relativa a una pagina inesistente (NoSuchPage.aspx), viene generata un'eccezione HttpException e viene visualizzata la pagina di errore personalizzata (si noti il riferimento a NoSuchPage.aspx nel aspxerrorpath parametro querystring).

Figura 6: Il runtime di ASP.NET visualizza la pagina Degli errori configurati in risposta a una richiesta non valida (fare clic per visualizzare l'immagine a dimensione intera)

Per impostazione predefinita, tutti i tipi di errori causano la visualizzazione della stessa pagina di errore personalizzata. È tuttavia possibile specificare una pagina di errore personalizzata diversa per un codice di stato HTTP specifico usando <error> elementi figlio all'interno della <customErrors> sezione . Ad esempio, per visualizzare una pagina di errore diversa in caso di errore di una pagina non trovata, con un codice di stato HTTP 404, aggiornare la <customErrors> sezione in modo da includere il markup seguente:

<customErrors mode="RemoteOnly" defaultRedirect="~/ErrorPages/Oops.aspx">
    <error statusCode="404" redirect="~/ErrorPages/404.aspx" />
</customErrors>

Con questa modifica apportata, ogni volta che un utente che visita in remoto una risorsa ASP.NET che non esiste, verrà reindirizzato alla 404.aspx pagina di Oops.aspxerrore personalizzata anziché a . Come illustrato nella figura 7 , la 404.aspx pagina può includere un messaggio più specifico rispetto alla pagina di errore personalizzata generale.

Figura 7: La pagina di errore personalizzata 404 visualizza un messaggio più mirato di Oops.aspx
(Fare clic per visualizzare l'immagine a dimensione intera)

Poiché si sa che la 404.aspx pagina viene raggiunta solo quando l'utente effettua una richiesta per una pagina che non è stata trovata, è possibile migliorare questa pagina di errore personalizzata per includere funzionalità che consentono all'utente di risolvere questo tipo di errore specifico. Ad esempio, è possibile creare una tabella di database che esegue il mapping di URL non validi noti a URL validi e quindi fare in modo che la 404.aspx pagina di errore personalizzata esegua una query su tale tabella e suggerisca pagine che l'utente potrebbe tentare di raggiungere.

Riepilogo

Quando si verifica un'eccezione non gestita in un'applicazione ASP.NET, l'utente viene visualizzato una delle tre pagine di errore: la schermata gialla della morte dei dettagli eccezione; l'errore di runtime Schermata gialla della morte; o una pagina di errore personalizzata. La pagina di errore visualizzata dipende dalla configurazione dell'applicazione <customErrors> e dal fatto che l'utente visiti in locale o in remoto. Il comportamento predefinito consiste nel mostrare i dettagli dell'eccezione YSOD ai visitatori locali e l'errore di runtime YSOD ai visitatori remoti.

Mentre l'errore di runtime YSOD nasconde le informazioni potenzialmente sensibili sugli errori dall'utente che visita il sito, si interrompe dall'aspetto del sito e rende l'applicazione buggy. Un approccio migliore consiste nell'usare una pagina di errore personalizzata, che comporta la creazione e la progettazione della pagina di errore personalizzata e la specifica dell'URL nell'attributo <customErrors> della defaultRedirect sezione. È anche possibile avere più pagine di errore personalizzate per diversi stati di errore HTTP.

La pagina di errore personalizzata è il primo passaggio di una strategia completa di gestione degli errori per un sito Web in produzione. L'invio di avvisi allo sviluppatore dell'errore e la registrazione dei relativi dettagli sono anche passaggi importanti. Le tre esercitazioni successive esplorano le tecniche per la notifica e la registrazione degli errori.

Buon programmatori!

Altre informazioni

Per altre informazioni sugli argomenti descritti in questa esercitazione, vedere le risorse seguenti:

• Pagine di errore, un'altra volta
• Linee guida di progettazione delle eccezioni
• Pagine di errore descrittive
• Gestione e generazione di eccezioni
• Uso corretto delle pagine di errore personalizzate in ASP.NET
• Cenni preliminari sulla funzionalità di traccia di ASP.NET