Eccezione rispetto al codice di ritorno in pattern DAO

Question

Eccezione rispetto al codice di ritorno in pattern DAO

#1 da (5 voti)
#2 da (3 voti)

5

Dopo aver letto molto sull'uso abusivo delle eccezioni in Java e su come dovresti far emergere un'eccezione attraverso i diversi livelli di un'applicazione, sono arrivato a un punto in cui non so cosa dovrei fare con i potenziali errori che la mia applicazione può avere.

Fondamentalmente, ho un webservice che usa il pattern DAO per accedere ai dati nel mio database. Tutte le azioni del database possono generare SQLException . Ad oggi, sto usando un try catch per catturare il SQLException e poi lanciamo un'eccezione definita specifica chiamata ExceptionDAO che sarà gestita dal webservice per restituire un messaggio corretto agli utenti (un'applicazione mobile) del mio servizio web.

Dopo aver letto molto su come l'eccezione dovrebbe essere eccezionale e non dovrebbe essere usata nel flusso di controllo, ho trovato una comprensione mista di cosa dovrei fare per gestire eventuali errori:

Utilizza i codici di ritorno per tutto ciò che è probabile che accada (ad esempio, il nome utente esiste già) e quindi, per rispettare il modello DAO, passa i miei oggetti di business come parametri. Potrei anche usare una coppia specifica che restituirebbe invece il codice + l'oggetto business. Il webservice utilizzerà quindi il codice di ritorno per visualizzare un messaggio specifico.
Utilizza le eccezioni controllate per tutto ciò che non posso prevedere avverrà e lascialo a diventare un webservice per gestire e restituire un messaggio agli utenti. (ad esempio, SQLException che non posso prevedere: connessione interrotta)
Lasciate che anche le eccezioni non selezionate si aprano e mostrino in questo caso una sorta di errore 404.

Ho anche dato uno sguardo al pattern null, ma non penso che si adatti bene a questa particolare situazione. Sono anche preoccupato di non dare troppe informazioni agli utenti, ma piuttosto utili e direttamente al punto informazioni. In effetti, i messaggi restituiti dal webservice verranno utilizzati da un'applicazione mobile per visualizzare un messaggio all'utente finale.

Spero di essere stato abbastanza chiaro riguardo al problema che sto avendo e non vedo l'ora di ricevere le vostre risposte!

NB. : Questo è il ripubblicare di un argomento che ho postato su StackOverflow, che riguarda la programmazione e non un problema specifico della lingua.

java exceptions web-services exception-handling

posta Jonathan Taws 22.02.2015 - 00:25

fonte

2 risposte

Leggi altre domande sui tag java exceptions web-services exception-handling

Come guida un team di tecnici, come devo gestire gli errori di codifica e le cattive pratiche dei membri del team? [duplicare] Quali alternative a un singleton ci sono per una classe che può avere solo un'istanza?

score 5 · Answer 1

Sulla saggezza convenzionale che afferma che devi solo generare un'eccezione quando si verifica una condizione che non puoi gestire nel tuo codice tendiamo a concentrarci sulla definizione di una condizione eccezionale ma ignori la definizione di cosa significhi gestire l'eccezione. Un processo può incontrare un'eccezione che comunica con un particolare nodo e può gestire l'eccezione reindirizzando la sua richiesta a un nodo di backup. Tuttavia, se una chiamata per creare una voce in una tabella non riesce a causa di un vincolo univoco come risultato di un valore immesso da un utente, l'unica entità che può veramente gestire la condizione è l'utente. Quindi questo è motivo per lanciare un'eccezione in quanto non puoi gestirlo nel tuo codice .

La semantica del tuo codice conta anche. Seguendo l'esempio della creazione di una nuova voce utente; una chiamata a isAvailableUserName(userName) non dovrebbe generare un'eccezione se userName esiste già nel database mentre una chiamata a createNewUser(userName) probabilmente dovrebbe. Una ragione per lanciare un'eccezione invece di usare un codice di ritorno è che i codici di ritorno in se stessi forniscono informazioni inadeguate e richiedono una tabella di ricerca o un enumer che diventa quindi un magnete di dipendenza. Le eccezioni invece sono più descrittive e contengono un messaggio, un backtrace, eccezioni nidificate, ecc. Le eccezioni rendono anche il tuo codice più pulito. Invece di avere un sacco di if annidati che esistono solo per testare le condizioni, il tuo codice può funzionare nel modo in cui si suppone e interrompe l'esecuzione quando accade qualcosa di brutto. Robert C. Martin nel suo libro "Clean Code" afferma che la gestione degli errori non dovrebbe oscurare la logica del codice. La pulizia del codice si applica anche al chiamante in quanto i codici di ritorno obbligano i chiamanti del codice a dover verificare eventuali errori subito dopo la chiamata. Poiché questo può essere facilmente dimenticato o ignorato, non è un buon approccio. Tuttavia, un'eccezione non può essere ignorata, ma deve essere gestita .

score 3 · Answer 2

Sembra che tu abbia qualche malinteso riguardo alle eccezioni, quindi proviamo a eliminarle prima.

Genera un'eccezione quando si verifica una condizione che non è possibile gestire nel codice.

Ad esempio, se il tuo codice dovrebbe aprire un file e fare qualcosa con quel file, ma l'utente fornisce un percorso a un file che non esiste, allora dovresti lanciare un'eccezione (o consentire a un'eccezione generata di andare lo stack di chiamate) perché l'utente ha creato condizioni in base alle quali il codice non può continuare ad essere eseguito in maniera significativa.

Risolvi un'eccezione quando vuoi registrare o modificare il tipo di eccezione.

Ad esempio, se vuoi scrivere un'eccezione in un log o fare qualcosa di simile che non corregge la condizione eccezionale, prendi l'eccezione, loggala e poi rethrow, magari con un'eccezione più appropriata al tuo codice specifico .

Un ultimo pensiero: le linee guida e le migliori pratiche del software sono proprio questo: le linee guida. Rispettali, ma fai ciò che è più appropriato per la tua situazione specifica. Se ciò significa rompere una linea guida, allora così sia. Non lasciare che le linee guida ostacolino una migliore programmazione. Non ci sono assoluti nella programmazione.