Approcci per la gestione dei codici di errore/dei messaggi in .NET

Question

Ricerca di suggerimenti/best practice sulla gestione dei codici di errore e dei messaggi in applicazioni multilivello. Specificamente cose come:

1. Dove devono essere definiti i codici di errore? Enum? Classe?
2. Come vengono associati i messaggi di errore o ulteriori dettagli ai codici di errore? file di risorse? attributi su valori enum, ecc.?
3. Se si dispone di un'applicazione multilivello composta da DAL, BLL, UI e progetti comuni, ad esempio, dovrebbe esserci un unico elenco gigante di codici per tutti i livelli o i codici sono estendibili per progetto/livello?

Aggiornamento: importante ricordare che non riesco a fare affidamento esclusivamente sulle eccezioni e tipi di eccezione personalizzata per la segnalazione degli errori, come alcuni clienti per questa applicazione sarà tramite servizi Web (SOAP & REST) ​​

Qualsiasi suggerimento benvenuto!

Answer 1

penso che sia meglio creare un progetto comune (o ApplicationFramework Project) e mettere le Eccezioni e Common Object su di esso.

E 'sempre una buona ideaavere un ApplicationFramework che contiene classe base per le classi (specialmente in UI - PageBase - MasterBase- ModuleBase ed ecc)

E come la sua evidente devi mettere le vostre classi ed Enum nel tuo progetto BLL.

Si noti che 3 livelli non significa 3 Progetto. Puoi avere 5 progetti nel tuo BLL.

Infine, non dimenticare di utilizzare ELMAH o altri strumenti simili.

Answer 2

I codici di errore sono di tipo old skool, erano necessari nei vecchi giorni di programmazione COM e C, ambienti che non supportavano eccezioni. Oggigiorno, si usano le eccezioni per notificare il codice client o l'utente in merito a problemi. Le eccezioni in .NET sono auto-descrittive, hanno un tipo, un messaggio e una diagnostica.

È necessario distinguere due tipi di eccezioni, quelle che sono ragionevolmente recuperabili e quelle in cui non si ha idea di cosa sia andato esattamente storto o come si ripristini da esse. Quest'ultimo tipo è di gran lunga il più comune, è necessario un essere umano per intraprendere azioni correttive. Utilizza uno dei tipi di eccezione .NET predefiniti standard per aumentarli. IllegalOperationException, FormatException, ArgumentException sono scelte comuni. Se è il back-end che solleva un'eccezione del genere, basta passarlo senza alterare. In genere, è necessario un blocco finale per garantire che lo stato interno sia coerente, a volte un blocco catch che contiene un lancio semplice per ripristinare lo stato.

Qualsiasi cosa si consideri recuperabile deve essere generato con un tipo di eccezione dichiarato dall'utente, derivato dalla classe Exception. Ciò dà al codice a monte la possibilità di scrivere una clausola di cattura e fare qualcosa di significativo. Dovrai generare un messaggio descrittivo del problema, nel caso in cui il codice up-stream non lo gestisca effettivamente, il testo del messaggio deve essere recuperato da una stringa hard-coded o da una risorsa se supporto localizzazione.