Dove devo gestire le eccezioni, in BLL, DAL o PL?

Question

Qual è il posto migliore per gestire le eccezioni? BLL, DAL o PL?

Devo consentire i metodi del DAL e BLL per lanciare le eccezioni a monte della catena e lasciare che il PL gestirli? o non li ho gestire al BLL?

es

Se ho un metodo nel mio DAL che le questioni "ExecuteNonQuery" e aggiorna alcuni record, ed a causa di uno o più motivi, 0 righe vengono colpiti. Ora, come devo lasciare che il mio PL sapere che se un'eccezione accaduto o c'era davvero nessuna riga corrispondenti alla condizione. Dovrei usare "try catturare" nel mio codice PL e farlo conoscere attraverso un'eccezione, o dovrei gestire l'eccezione al Dal e restituire un codice speciale come (-1) per lasciare che il differenziare tra il PL (eccezione) e (no righe abbinati condizione cioè zero righe interessate)?

Answer 1

Non ha senso lasciare che un eccezione che viene generata nella bolla DAL fino al PL - come è l'utente dovrebbe reagire se non è possibile stabilire la connessione al database

Catch and eccezioni di handle presto, se è possibile gestirli. Non appena li ingoiare senza emettere un suggerimento o un messaggio di log -. questo porterà a gravi difficoltà e bug che sono difficili da rintracciare

Answer 2

Questo è un argomento enorme con un sacco di polemiche non necessari (le persone con voci alte dare cattive informazioni!) Se siete disposti a trattare con questo, seguire il consiglio di s1mm0t, è per lo più gradevole.

Tuttavia, se si desidera una sola parola risposta, metterli in PL. Grave. Se si riesce a farla franca mettere la vostra gestione degli errori in un gestore di eccezioni globale (tutti gli errori devono accedere e dare un codice per cercare il log in produzione per motivi di sicurezza (specialmente se web), ma dare tutti i dettagli indietro durante lo sviluppo per ragioni di velocità).

Modifica: (chiarimento) bisogna fare i conti con alcuni errori ovunque - ma questa non è una norma 'ogni funzione'. La maggior parte del tempo lasciarli bolla fino al PL e gestire l'errore globale di NET con il proprio codice: log lo stack di chiamate completo da lì tramite una routine comune che è accessibile da tutti e 3 i livelli tramite i gestori di eventi (vedi EDIT nella parte inferiore del messaggio ). Questo significa che sarà non hanno try / catch cosparso attraverso tutto il codice; solo le sezioni che ci si aspetta ed errori e in grado di gestire proprio lì, o, le sezioni non critiche, con il quale si accede l'errore e informare l'utente funzionalità non disponibili (questo è ancora più raro e per i programmi di super-affidabile / critico)

A parte questo, quando si lavora con gli elementi di risorse limitate, io spesso uso la parola 'utilizzando' o try / finally / fine prova senza il fermo. per il multithreading bandiere di blocco / mutex / prevenzione di rientro / etc. È inoltre necessario try / finally nei casi tutto in modo che il programma funziona ancora (soprattutto applicazioni stateful).

Se si sta utilizzando in modo improprio le eccezioni (per esempio, a che fare con i non-bug quando si dovrebbe utilizzare l'istruzione if o il controllo è un'operazione incerto funzionerà prima di provare), questa filosofia si scompone più.

Una nota a margine, in spessore cliente applicazioni soprattutto quando v'è la possibilità di perdere una quantità significativa o l'ingresso degli utenti, potrebbe essere meglio con più try / catture in cui si tenta di salvare i dati (contrassegnati come non-ancora- valido naturalmente).

EDIT: un altro bisogno per almeno avere il la registrazione di routine nella PL - questo funzionerà in modo diverso a seconda della piattaforma. Un app stiamo lavorando su azioni della BLL / DAL con 3 versioni: una versione PL ASP.Net, una versione WinForms, e una modalità di regressione console app lotto test versione. La routine di registrazione che si chiama in realtà è nel BLL (il DAL getta solo gli errori o totalmente gestisce qualsiasi ottiene o ri-getta). Tuttavia questo solleva un evento che viene gestito dal PL; sul web lo mette nel registro del server e non visualizzazione dei messaggi di errore in stile web (messaggio amichevole per la produzione); in WinForms una finestra speciale messaggio appare con il prodotto Informazioni di supporto, ecc e registra l'errore dietro le quinte (gli sviluppatori possono fare qualcosa 'segreto' per vedere le informazioni completo). E, naturalmente, nella versione di prova è un processo molto più semplice, ma diverso pure.
Non sono sicuro di come avrei fatto che nel BLL eccezione per il passaggio di un parametro 'quale piattaforma,' ma dal momento che non include WinForms o librerie asp che la registrazione dipende, che ancora sarebbe un trucco.

Answer 3

La risposta breve è che dipende!

Si deve sempre e solo gestire un'eccezione se si può fare qualcosa di utile con esso. Il 'qualcosa di utile' dipende ancora una volta quello che state facendo. Si consiglia di registrare i dettagli di eccezione, anche se questo non è davvero maneggiarlo e si dovrebbe davvero ri-generare l'eccezione dopo l'accesso nella maggior parte dei casi. Si consiglia di avvolgere l'eccezione in qualche altra eccezione (eventualmente personalizzato) al fine di aggiungere ulteriori informazioni per l'eccezione. Come tocchi @mbeckish su, si consiglia di cercare di recuperare l'eccezione per ritentare l'operazione per esempio - si deve fare attenzione a non ripetere per sempre però. Infine (scusate il gioco di parole) si consiglia di utilizzare un blocco finally per ripulire tutte le risorse come ad esempio una connessione DB aperto. Che cosa si sceglie di fare con l'eccezione influenzerà dove gestirlo. E 'probabile che non v'è una grande quantità di cose utili che si possono fare con molte eccezioni se non per segnalare all'utente che si è verificato un errore, nel qual caso sarebbe più che accettabile per gestire l'eccezione nello strato di interfaccia utente e segnalare il problema per l'utente (probabilmente si dovrebbe registrare l'eccezione, nonché, più in basso i livelli).

Quando generare eccezioni da soli, si deve sempre e solo buttare eccezioni in 'exceptional'circumstances in quanto v'è un grande testa a generare eccezioni. Nel tuo esempio suggerisci si può pensare di lanciare un'eccezione se nessun record vengono aggiornati dalla vostra operazione. Questa è davvero eccezionale? Una cosa di meglio da fare in questa situazione sarebbe quella di restituire il numero di record aggiornati - questa può essere ancora una condizione di errore che deve essere segnalato per l'utente, ma non è eccezionale come il comando in errore perché il connecction al DB ha giù andato.

Questo è un articolo ragionevole sulla gestione delle eccezioni migliore pratiche.

Answer 4

Lo strato che sa cosa fare per le cose set destra dovrebbe essere il livello che gestisce l'eccezione. Ad esempio, se si decide di gestire gli errori deadlock dal ritentare l'interrogazione di un certo numero di volte, allora si potrebbe costruire che nel vostro DAL. Se continua a fallire, allora si potrebbe desiderare di lasciare che la bolla eccezione fino al livello successivo, che può quindi decidere se sa come gestire correttamente questa eccezione.

Answer 5

Tutti i livelli nella vostra applicazione dovrebbe gestire le eccezioni gracefullly. Questo è conosciuto come un corncern trasversale, perché appare in tutti i livelli. I belive che l'utilizzo di un framework come Enterprise Eccezione blocco con l'unità, si finirà con un codice di meglio in generale. Date un'occhiata a questo post

http://msdn.microsoft. com / it-it / library / ff664698 (v = PandP.50) aspx

Ci vorrà del tempo prima di dominarlo, ma ci sono un sacco di esempi e screencast lì intorno.

Answer 6

Come gestire le eccezioni dipende dalle esigenze tecniche e di business. Per aggiornamenti di database complessi o altamente importanti includo fuori params che passano un piccolo elenco di errori noti di backup al DL. In questo modo, scenari di errore può essere conosciuti programmazione risolto in alcuni casi. In altri casi, l'errore deve essere registrato e l'utente deve essere informato di un errore.

I fare una pratica di notificare un essere umano di errori. Certo, la registrazione ci darà informazioni dettagliate, ma è nessuna sostituzione per il tempo di risposta di un essere umano. Non solo, ma il motivo per cui gli sviluppatori di forza di guardare i log di sistema solo per vedere se le cose stanno andando a sud? Parlare di costi inutili.

Se avete tempo per definire i potenziali errori / eccezioni e programmaticamente risolverli, quindi con tutti i mezzi lo fanno. Molte volte gli errori / eccezioni sono inaspettati. Ecco perché è importante essere preparati per questo inaspettato e quale modo migliore per farlo se non coinvolge un essere umano.

Nel complesso, uno dovrebbe essere sulla difensiva quando si pianifica la gestione delle eccezioni. Programmi crescono o muoiono. Una parte della crescita è l'introduzione di insetti. Quindi non girare le ruote cercando di ucciderli tutti.

Answer 7

La domanda è dove è l'eccezione rilevante? Se si tratta di un'eccezione di accesso ai dati deve essere catturato nel DAL. Se si tratta di un'eccezione logica dovrebbe essere catturato nel BLL. Se si tratta di un'eccezione presentazione poi nel PL.

Per esempio se il vostro DAL genera un'eccezione che dovrebbe restituire un nullo o un falso o qualunque sia il caso al vostro BLL. Il tuo BLL dovrebbe sapere cosa fare se il DAL restituisce un valore nullo, forse passa proprio attraverso, forse tenta di chiamare un'altra funzione, ecc Lo stesso vale con il tuo PL se la BLL passa attraverso un nulla dal DAL o ritorna qualcosa di specifico proprio allora il livello di presentazione dovrebbe essere in grado di informare l'utente finale che c'era un problema.

Naturalmente non sarà possibile ottenere il verbose messaggi di eccezione, ma che è una buona cosa per quanto riguarda gli utenti sono interessati. Si dovrebbe avere un sistema di registrazione flessibile per catturare queste eccezioni e segnalarli a un database o un ip: porto o qualunque cosa tu decida.

In sostanza è necessario pensare in termini di separazione degli interessi se la preoccupazione è un dato problema o un problema di logica dovrebbe essere gestita di conseguenza.