Eccezioni e Astrazioni

Question

Quando si deve lanciare un'eccezione personalizzata?

es. Ho qualche codice che connette a un server. Il codice che si connette al server genera un IOException quando non riesce a connettersi. Nel contesto del metodo si chiama, questo va bene. E 'bene anche nel codice di rete.

Ma poiché questo non rappresenta avendo una connessione (e quindi non funzionare) l'eccezione va tutto il senso fino alla ui. In questa fase, un'IOException è molto ambiguo. Qualcosa di simile NoConnectionException sarebbe meglio.

Quindi, la mia domanda è: A che punto si dovrebbe rilevare un'eccezione per gettare invece un'altra eccezione (personalizzato) che meglio si adatta l'astrazione?

Answer 1

mi aspetterei eccezioni a parlare in termini di quello che ho chiesto il metodo di origine a fare. per es.

read -> ReadException
connect -> ConnectException
buildPortfolio -> FailedToBuildPortfolioException

ecc. Questo astrae cosa sta succedendo sotto le coperte (vale a dire Si sta collegando via socket, ecc). Come regola generale, quando si crea un'interfaccia per un componente, spesso a creare una corrispondente eccezione o insieme di eccezioni. La mia interfaccia sarà chiamato Component, e le mie eccezioni sono di solito ComponentException (ad esempio RateSource e RateSourceException). E 'coerente e facile da esportare in diversi progetti come set componente completo.

Lo svantaggio è che si crea un bel po 'di eccezioni, e potrebbe essere necessario eseguire un bel po' di traduzioni. Il vantaggio è che (come hai identificato) si ottiene poco o nessun perdite astrazione.

Ad un certo punto durante la gerarchia delle chiamate di metodo (e quindi eccezioni) si può decidere che nessun recupero può avvenire (o è in un luogo inappropriato) e tradurre le eccezioni non controllate da trattare in seguito.

Answer 2

So che questo è etichettato come "lingua-agnostic", ma non credo che realmente è. Venendo dal punto di vista di un C ++, mi aspetto molto alcune operazioni di base per generare un'eccezione - la libreria standard C ++ utilizza solo eccezioni in pochissimi posti. Quindi il mio codice è spesso il primo luogo in cui le eccezioni possono essere generati. In quel codice, mi piace una gerarchia molto piatto - Non voglio essere pasticciano con centinaia di cattura () clausole più avanti nel codice, e non ho mai capito Java e apparente ossessione C # s 'con la creazione di gerarchie barocchi di classe e di spazio dei nomi <. / p>

Quindi, per il mio codice C ++ - un tipo di eccezione, che contiene un messaggio di errore significativo, per libreria. E uno per l'eseguibile finale.

Answer 3

Credo che ci siano due questioni nascosti qui: a) Quando si dovrebbe nascondere dietro un'eccezione un'eccezione diversa. b) Quando si dovrebbe utilizzare un eccezione personalizzata per questo.

a) direi: quando mai un'eccezione viaggia attraverso il confine di due strati nella domanda, si dovrebbe avere nascosto dietro un'eccezione che è più appropriato per il nuovo livello. Esempio:., Perché si sta facendo alcune cose a distanza, si ottiene un ConnectionWhatEverException

Ma il chiamante non deve essere a conoscenza di problemi di connessione. Dal momento che lui vuole solo per ottenere qualche servizio svolto, così lui ottiene un ServiceOutOfOrderException. La ragione di questo è: all'interno dello strato, facendo servizi remoti, si potrebbe fare qualcosa di utile con un ConnectionException (riprovare, scrivere in una coda di backout ..). Una volta che hai lasciato quello strato, nessuno sa come gestire un ConnectionException. Ma dovrebbero essere in grado di decidere, che cosa fare, quando il servizio non funziona.

b) Se non v'è alcuna corrispondenza esistente Exception. Ci sono un paio di eccezioni utile in Java, per esempio. Io uso IllegalState e IllegalArgument abbastanza spesso. Un forte argomento a favore di una nuova classe di eccezioni è, se si dispone di un contesto utile per fornire. Ad esempio, il nome del servizio che non è riuscita potrebbe essere un argomento di una ServiceFailedException. Basta non creare una classe per ogni chiamata di metodo, o qualcosa in tal senso. 100 classi di eccezione non sono un problema, fintanto che hanno un comportamento diverso (cioè almeno diversi campi). Se differiscono solo per nome e risiedono sullo stesso livello di astrazione, li rendono una sola eccezione, e mettere i diversi nomi nel messaggio o di un singolo campo di quella classe di eccezione.

c) almeno in Java c'è la discussione su eccezioni controllate. Mi avvolgo quelli direttamente in un incontrollato, perché odio il tipo controllato. Ma questo è più un parere quindi consiglio.

Answer 4

C'è un caso in cui si otterrebbe NoConnectionException che non è causato da un problema IO? Al contrario, è sapere se la causa si basa IO o non andare per aiutare il cliente a recuperare sensibilmente?

Answer 5

  

Quando si deve lanciare un'eccezione personalizzata?

I. Quando si può fornire maggiori informazioni (diagnostica).

Nota: queste informazioni aggiuntive potrebbero non essere disponibili nel luogo in cui è stato gettato l'eccezione originale (IOException). strati progressivi di astrazioni possono avere più informazioni da aggiungere come quello che stavi cercando di fare che ha portato a questa eccezione?

II. Quando non è necessario esporre i dettagli di implementazione: vale a dire che si desidera che il (illusione di?) L'astrazione per continuare.

Ciò può essere importante quando il meccanismo di attuazione sottostante può cambiare. Avvolgendo l'eccezione sottostante un'eccezione personalizzato è un buon modo di isolare i vostri clienti dai dettagli di implementazione (alzando il livello di astrazione)

III. Sia I e II

NOTA: Inoltre i vostri clienti dovrebbero essere in grado di entrare in sintonia con l'esatto livello di informazioni che sono interessati o piuttosto dovrebbero essere in grado di sintonizzarsi su tutto ciò che non sono interessati a Quindi è una buona idea di derivare le vostre eccezioni personalizzate da. IOException.