Gestione delle eccezioni nelle app Web .net

Question

Lo ammetto:Non mi preoccupo troppo della gestione delle eccezioni.So che dovrei fare di più, ma non riesco mai a capire dove iniziare e dove fermarmi.Non sono pigro.Lontano da esso.È che sono oberato dall'ambivalenza nella gestione delle eccezioni.Sembra proprio che ci sia un numero apparentemente infinito di posti anche nell'app più piccola in cui è possibile applicare la gestione delle eccezioni e può iniziare a sembrare eccessivo.

Sono riuscito a cavarmela con test attenti, convalide e preghiere silenziose, ma questo è un brutto incidente di programmazione in attesa di accadere.

Quindi, quali sono le migliori pratiche per la gestione delle eccezioni?In particolare, dove sono i luoghi più ovvi/critici in cui dovrebbe essere applicata la gestione delle eccezioni e dove sono i luoghi in cui dovrebbe essere presa in considerazione?

Mi scuso per la domanda vaga, ma voglio davvero chiudere il libro su questo argomento una volta per tutte.

Answer 1

Quello di Microsoft Team di modelli e pratiche ha fatto un buon lavoro incorporando le migliori pratiche di gestione delle eccezioni nella Libreria aziendale Blocco applicazione gestione eccezioni

Evento se non utilizzassi Enterprise Library, I altamente ti consiglio di leggere la loro documentazione.Il team P&P descrive scenari comuni e best practice per la gestione delle eccezioni.

Per iniziare ti consiglio di leggere i seguenti articoli:

• La gestione delle eccezioni su MSDN
• Gestione delle eccezioni in .NET su MSDN
• Procedure consigliate per la gestione delle eccezioni in .NET su CodeProject

Articoli specifici di ASP.NET:

• Gestione delle eccezioni ASP.NET intuitiva
• Gestione delle eccezioni globali con ASP.NET
• Gestione delle eccezioni in C# e ASP .NET

Answer 2

La regola d'oro con la gestione delle eccezioni è:

"Prendi solo ciò che sai maneggiare"

Ho visto troppi blocchi try-catch in cui il catch non fa altro che rilanciare l'eccezione.Ciò non aggiunge alcun valore.Solo perché chiami un metodo che ha il potenziale per generare un'eccezione non significa che devi gestire la possibile eccezione nel codice chiamante.Spesso è perfettamente accettabile lasciare che le eccezioni si propaghino nello stack di chiamate verso qualche altro codice che sa cosa fare.In alcuni casi, è valido lasciare che le eccezioni si propaghino fino al livello dell'interfaccia utente per poi catturare e visualizzare il messaggio all'utente.Potrebbe darsi che nessun codice sia nella posizione migliore per sapere come gestire la situazione e che l'utente debba decidere la linea di condotta.

Answer 3

Ti consiglio di iniziare aggiungendo una buona pagina di errore che catturi tutte le eccezioni e stampi un messaggio leggermente meno ostile per l'utente.Assicurati di registrare tutti i dettagli disponibili dell'eccezione e di rivederli.Fai sapere all'utente che lo hai fatto e forniscigli un collegamento a una pagina che (probabilmente) funzionerà.

Ora, utilizza quel registro per rilevare dove dovrebbe essere implementata la gestione speciale delle eccezioni.Ricorda che non è utile intercettare un'eccezione a meno che tu non preveda di farci qualcosa.Se è attiva la pagina precedente, non è utile rilevare individualmente le eccezioni del database su tutte le operazioni db, a meno che non si disponga di un modo specifico per il ripristino in quel punto specifico.

Ricordare:L'unica cosa peggiore che non individuare le eccezioni è individuarle e non fare nulla.Questo nasconderà solo i veri problemi.

Answer 4

Potrebbe riguardare più la gestione delle eccezioni in generale che la specifica ASP.NET ma:

• Cerca di catturare le eccezioni il più vicino possibile alla causa in modo da poter registrare (registro) quante più informazioni possibile sull'eccezione.
• Includi una qualche forma di catch All, Last Resort Excesment Handler nei punti di ingresso del programma.In ASP.NET questo potrebbe essere il gestore degli errori del livello dell'applicazione.
• Se non sai come gestire "correttamente" un'eccezione, lasciala emergere fino al gestore catch all dove puoi trattarla come un'eccezione "inaspettata".
• Usa i metodi Try ***** in .NET per cose come l'accesso a un dizionario.Questo aiuta a evitare importanti problemi di prestazione (la gestione delle eccezioni è relativamente lenta) se si lancia più eccezioni in un ciclo.
• Non utilizzare la gestione delle eccezioni per controllare la normale logica del programma, ad esempioUscendo da un ciclo tramite una dichiarazione di lancio.

Answer 5

Inizia con un gestore di eccezioni globali come http://code.google.com/p/elmah/.

Quindi la domanda si riduce a che tipo di applicazione stai scrivendo e che tipo di esperienza utente devi fornire.Più ricca è l'esperienza dell'utente, migliore sarà la gestione delle eccezioni che vorrai fornire.

Ad esempio, considera un sito di hosting di foto che dispone di quote disco, limiti di dimensione dei file, limiti di dimensione delle immagini, ecc.Per ogni errore potresti semplicemente restituire "Si è verificato un errore.Per favore riprova".Oppure potresti entrare nella gestione dettagliata degli errori:

• "Il tuo file è troppo grande.Fixeize massimi sono 5 MB. "
• "La tua immagine è troppo grande.Le dimensioni massime sono 1200x1200. "
• "Il tuo album è pieno.La capacità massima di archiviazione è 1 GB".
• "C'è stato un errore con il tuo caricamento.I nostri criceti sono infelici.Per favore ritorna più tardi."

eccetera.eccetera.

Non esiste una soluzione valida per tutti per la gestione delle eccezioni.

Answer 6

Bene, a livello base dovresti gestire l'evento HttpApplication.Error nel file Global.asax.Questo dovrebbe registrare qualsiasi eccezione che si verifica in un unico posto in modo da poter rivedere l'analisi dello stack dell'eccezione.

A parte questo livello di base, dovresti idealmente gestire le eccezioni in cui sai che puoi ripristinarle, ad esempio se prevedi che un file possa essere bloccato, gestire l'IOException e segnalare l'errore all'utente sarebbe una buona idea.