Standard aziendale per il flusso di eccezioni

Question

Standard aziendale per il flusso di eccezioni

#1 da (2 voti)
#2 da (-1 voti)

0

Qual è lo standard aziendale comunemente accettato per la gestione delle eccezioni?

Considera che il progetto ha una struttura a tre livelli.

- Controller  
- Service throws ServiceException
- Dao throws DaoException

È il modo giusto per rilevare l'eccezione DAO nel livello di servizio e convertirli in un'eccezione di servizio?
Ancora una volta cattura l'eccezione Servizio nella classe Controller e invia un messaggio significativo all'utente senza rivelare alcuna entità aziendale. Questo approccio è accettabile o devo consentire che l'eccezione DAO passi al controller o ad altri pensieri ??

exceptions

posta Arun 26.05.2017 - 20:39

fonte

2 risposte

Leggi altre domande sui tag exceptions

Qual è il modo migliore per passare la configurazione specifica del provider a oggetti diversi In che modo i modelli di I / O di basso livello sono mappati nell'astrazione di I / O del flusso?

score 2 · Answer 1

C'è una buona pratica è quella di lanciare presto, prendere tardi .

Is it right way to catch the DAO exception in Service layer and convert them to a Service exception?

Sul ServiceLayer, invece di "convertire" un'eccezione (e probabilmente perdere alcune informazioni significative) è meglio ripetere l'eccezione con i dettagli delle operazioni avanzate. Ciò semplificherà ulteriormente l'analisi delle eccezioni poiché, ad eccezione dei dettagli tecnici di basso livello di DAL, ci sarà più descrizione di alto livello dell'intenzione iniziale.

catch the Service exception in Controller class and send a meaningful message to user without disclosing any business entities.

Non dovresti affidarti alle eccezioni per indirizzare il flusso dell'app. Le eccezioni sono per situazioni eccezionali . Nel controller, invece di chiamante API di servizio (e in attesa di un'eccezione da restituire all'utente) puoi progettare la tua API in un modo che ti permetta di chiedere se un'operazione è permesso o meno. In caso contrario, mostrare un errore dell'utente; in caso affermativo, chiama l'API.

Tutte le eccezioni impreviste dovrebbero essere gestite in modo centralizzato in un unico luogo. Puoi restituire un messaggio di errore generale all'utente.

score -1 · Answer 2

Le eccezioni dovrebbero essere riservate a situazioni eccezionali: qualcosa di completamente inatteso (cioè un bug) o qualcosa che impedisce completamente al tuo codice di svolgere la sua funzione (ad es. il tuo database non è disponibile). In entrambi i casi, questo non è qualcosa a cui un utente può fare affidamento e quindi mi limito a registrare quante più informazioni possibile ea visualizzare un messaggio generico all'utente per fargli sapere come si presenta il processo di supporto (ad esempio contatta il tuo amministratore) .

Non fare in modo che ogni livello lanci il proprio tipo di eccezione - l'unica ragione per creare un nuovo tipo di eccezione è se si desidera aggiungere più informazioni contestuali sotto forma di proprietà all'eccezione, o se si vuole essere in grado per cogliere questa eccezione (che è molto rara - se la tua applicazione sta rilevando un'eccezione è un'indicazione che forse l'eccezione non è eccezionale).

I Non rilevo eccezioni a meno che non sia possibile:

Aggiungi informazioni, ad es. se sto elaborando una lista di oggetti potrei prenderli tutti eccezioni e rilancia un'eccezione wrapper che include informazioni sull'elemento in fase di elaborazione
Gestisci l'eccezione, ad es. cattura un'eccezione specifica che so di poter recuperare (normalmente generata da un gruppo di terze parti) o nei livelli più esterni in modo da poter registrare l'eccezione e segnalare un errore all'utente

Se rilevi e rilancia un'eccezione, fai attenzione a non perdere informazioni che potrebbero aiutarti a diagnosticare il problema, in particolare lo stack di chiamate. Catching e re-throwing di tutte le eccezioni come generico ServiceException è un modo infallibile per rendere i bachi molto più difficili da diagnosticare.