Dovrei sempre lanciare il più specifico o dovrei provare a generalizzare i tipi di eccezione?

Question

Dovrei sempre lanciare il più specifico o dovrei provare a generalizzare i tipi di eccezione?

#1 da (5 voti)

6

Di solito hai FooException .

/**
 * @throw FooException If Foo is invalid for searching.
 */
public bool exists(Foo a)

Ma a un certo punto devi avere altre due eccezioni specifiche per Foo.

/**
 * @throw FooSearchException (extends FooException) When "a" caused the error.
 * @throw FooReplacementException (extends FooException) When "b" caused the error.
 */
public int replace(Foo a, Foo b)

Perché vuoi sapere quale dei due parametri ha causato l'errore.

A questo punto, cosa devo fare con il metodo exists() ? Dovrei cambiarlo in lanciare il tipo di eccezione più specifico o dovrei mantenerlo il più possibile generalizzato per identificare in modo univoco un problema in una singola routine ? Il metodo exists() non ha bisogno di distinguere tra Search e Replacement parametri, ma è ancora circa un Search . Cosa dovrei fare?

(Tieni presente che la modifica non avrà effetto su catch() es esistente poiché sia FooSearchException che FooReplacementException estendono FooException )

design object-oriented-design exceptions hierarchy

posta Wes 01.04.2015 - 16:44

fonte

1 risposta

Leggi altre domande sui tag design object-oriented-design exceptions hierarchy

Migrazione del codice base - vecchio sistema di controllo delle versioni su moderno Qual è l'approccio corretto per creare un'applicazione attorno a una libreria?

score 5 · Accepted Answer

Getta l'eccezione più specifica che esiste già. Non fa male al chiamante a cui non interessa e cattura solo la superclasse comune più generale, ma aggiunge un'ulteriore flessibilità extra a un chiamante che li distingue.

Sii desideroso di cambiare il codice esistente da generale → specifico. Dopotutto non dovrebbe rompere il codice.

Fai attenzione a cambiare il codice esistente da specifici → generali, poiché si tratta di un cambiamento più grave. Se ti rendi conto che anche un altro caso dovrebbe essere soddisfatto, allora non hai altra scelta: non fingere mai un'eccezione generale con un caso più specifico che non si applica.

Tuttavia non essere incoerente nella tua specificità: immagina un metodo che ha preso un parametro x e un y e se x è fuori da un intervallo specifico genera un'eccezione "argomento fuori intervallo", ma se y è fuori da un intervallo specifico genera un'eccezione generale "argomento" perché la cattura insieme ad altri problemi con y . Il risultato sarebbe solo confuso. (Va bene, ad esempio, lanciare "argomento fuori intervallo" se x o y sono fuori dai rispettivi intervalli e "eccezione argomento" se la combinazione di x e y è al di fuori di un intervallo collettivo) .

Quello che non sto trattando qui è la questione di quando creare un altro tipo di eccezione per essere più specifico di quello che hai già ottenuto, che è una domanda molto più coinvolgente. Però dico che penso che valga la pena considerarli come "costare" qualcosa; se stai "spendendo", allora cosa ottieni per le tue spese?