Visualizzazione di una pagina di errore personalizzata (VB)

di Scott Mitchell

Cosa viene visualizzato dall'utente quando si verifica un errore di runtime in un'applicazione Web ASP.NET? La risposta dipende da come è configurato il <customErrors> del sito Web. Per impostazione predefinita, agli utenti viene mostrata una schermata gialla sgradevole 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 del sito.

Introduzione

In un mondo perfetto non ci sarebbero errori di run-time. I programmatori scriverebbero codice senza alcun bug e la convalida dell'input utente sarebbe affidabile e risorse esterne come server di database e server di posta elettronica non andrebbero 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 si propaga lungo lo stack delle chiamate alla ricerca di blocchi Try/Catch/Finally.

Se l'eccezione raggiunge il runtime di ASP.NET senza essere gestita, l'evento della classe HttpApplication viene generato e viene visualizzata la pagina di errore configurata. Per impostazione predefinita, ASP.NET visualizza una pagina di errore denominata YSOD ( Yellow Screen of Death ). 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 semplicemente indica che si è verificato un errore di run-time (vedere la figura 2).

I dettagli dell'eccezione YSOD sono molto utili per gli sviluppatori che eseguono il debug dell'applicazione, ma mostrare un YSOD agli utenti finali è poco professionale. Gli utenti finali devono invece essere visualizzati in una pagina di errore che mantiene l'aspetto del sito con una 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 alle diverse pagine di errore di ASP.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 visualizzato uno dei tre tipi di pagine di errore:

• La pagina di errore "Schermata gialla della morte" con dettagli sull'eccezione
• Pagina di errore di runtime, schermata gialla della morte o
• Pagina di errore personalizzata

Gli sviluppatori della pagina di errore hanno più 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, il dettaglio dell'eccezione YSOD fornisce informazioni dettagliate sull'eccezione, ovvero il tipo, il messaggio e la traccia dello stack. Inoltre, se l'eccezione è stata generata dal codice nella classe code-behind della pagina ASP.NET e se l'applicazione è configurata per il debug, i dettagli dell'eccezione YSOD mostreranno 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. Ricorda che la Genre.aspx pagina elenca le recensioni dei libri in un particolare genere. Richiede che il GenreId valore (un uniqueidentifier) venga passato tramite la stringa di query. Ad esempio, l'URL appropriato per visualizzare le recensioni 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 dell'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 tale YSOD un aspetto non professionale.

Per impostazione predefinita, l'errore di runtime YSOD viene visualizzato agli utenti che visitano in modalità remota (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 hai 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 stessi stili delle altre pagine. La sezione "Uso 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'anteprima di questa pagina di errore personalizzata. Come si può notare, l'aspetto della pagina degli errori è molto più professionale di uno dei schermi gialli della morte mostrati 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)

Prenditi un momento per 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 sta visitando 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 dell'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 funge da se avessi impostato l'attributo mode su RemoteOnly e non avessi specificato un defaultRedirect valore. In altre parole, il comportamento predefinito è che i dettagli dell'eccezione YSOD vengono visualizzati ai visitatori locali mentre viene visualizzato l'errore di runtime YSOD ai visitatori remoti. È possibile eseguire l'override di questo comportamento predefinito aggiungendo una <customErrors> sezione all'applicazione Web Web.config file.

Utilizzo 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 da creare e la configurazione dell'applicazione per l'uso della pagina di errore personalizzata richiede solo pochi 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. Assicurati che la pagina utilizzi la stessa pagina master del resto delle pagine del tuo sito, in modo che erediti automaticamente lo stesso aspetto e sensazione.

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)

Dopo aver completato la pagina di errore, configurare l'applicazione Web in modo da usare la pagina di errore personalizzata al posto dell'errore di runtime YSOD. Questa operazione viene eseguita specificando 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 per visualizzare 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 visualizzarlo 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. Verranno comunque 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.

Notificare gli sviluppatori e registrare i dettagli degli errori

Gli errori che si verificano nell'ambiente di sviluppo sono stati causati dallo sviluppatore seduto nel computer. Le informazioni dell'eccezione vengono mostrate nei dettagli dell'eccezione YSOD, e lei 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 del fatto che si è verificato un errore a meno che l'utente finale che visita il sito non richiede tempo per segnalare l'errore. E anche se l'utente si sforza 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, figuriamoci 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 soluzione 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 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 entra nel 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 .HttpException Questa eccezione, come le eccezioni sollevate dalle pagine ASP.NET, si propaga al runtime, causando la visualizzazione della pagina di errore appropriata.

Ciò significa che per l'applicazione Web in produzione è che se un utente richiede una pagina che non viene trovata, visualizzerà 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 configurata 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 diversa pagina di errore personalizzata per un codice di stato HTTP specifico, usando elementi figlio <error> all'interno della sezione <customErrors>. Ad esempio, per visualizzare una pagina di errore diversa in caso di errore di 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 in vigore, ogni volta che un utente che effettua visite in remoto richiede una risorsa ASP.NET che non esiste, verrà reindirizzato alla pagina di errore personalizzata 404.aspx anziché a Oops.aspx. 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 è certi che la 404.aspx pagina viene raggiunta solo quando l'utente effettua una richiesta per una pagina non 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.

Sommario

Quando si verifica un'eccezione non gestita in un'applicazione ASP.NET, l'utente visualizza una delle tre pagine di errore seguenti: dettagli eccezione schermata gialla della morte; 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 localmente 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 informazioni sugli errori potenzialmente sensibili dall'utente che visita il sito, interrompe l'estetica del sito e rende l'applicazione difettosa. 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 illustrano le tecniche per la notifica e la registrazione degli errori.

Buon programmatori!

Altre informazioni

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

• Pagine di errore, un'altra volta
• Linee guida di progettazione per le eccezioni
• Pagine di errore intuitive
• gestione e generazione di eccezioni
• Uso corretto delle pagine di errore personalizzate in ASP.NET