Pro e contro delle eccezioni personalizzate [duplicato]

4

Questa potrebbe essere una domanda inutile basata sull'opinione, lo stile e il contesto, ma mi sono tormentato il cervello nel tentativo di decidere se fare o meno eccezioni personalizzate e mi piacerebbe sentire alcuni pro e contro da parte di chiunque abbia esperienza da entrambi gli approcci.

Ad esempio, sto cercando di decidere tra una ObjectNotFoundException personalizzata e IllegalArgumentException / IllegalStateException.

(Si noti che non intendo lanciare un'eccezione ogni volta che un servizio non è in grado di trovare un oggetto con un identificatore dato. In tal caso, restituiamo semplicemente un valore nullo.Io parlo di quando un'azione deve essere eseguita su un oggetto con un identificatore dato. In questo caso, ci si aspetta che l'oggetto in questione esista, quindi se non lo fa, vogliamo lanciare un'eccezione.)

Da una parte, una "GiraffeNotFoundException" è esplicita e potrebbe essere gestita in modo diverso da una generica IllegalStateException, ma poi di nuovo suppongo che sarebbe importante se tale differenziazione fosse effettivamente richiesta. Un altro pro è che un messaggio personalizzato per tale eccezione può essere impostato come messaggio predefinito per questa eccezione (riducendo un po 'di ridondanza).

D'altra parte, potrebbe non essere una buona idea ingombrare il codice sorgente con eccezioni personalizzate. Anche con le eccezioni standard, la classe Assert di Spring può essere utilizzata in modo abbastanza efficiente. Non ci sono intenzioni di pubblicare il nostro codice come libreria di terze parti, quindi non ci sono pressioni per l'utilizzo di eccezioni standard da quella parte.

Qualche altro pensiero?

    
posta kennyg 03.07.2014 - 16:53
fonte

1 risposta

4

Nella mia esperienza, dipende da quanto devi fare una volta che hai preso l'eccezione.

Se è necessario propagarlo ulteriormente dopo aver chiuso alcune risorse, non è necessario creare le proprie eccezioni.

Se hai bisogno di fare un lavoro complesso a seconda di cosa fallisce e in che modo - le eccezioni personalizzate sono tuoi amici. Se usi solo un singolo IllegalArgumentException - come fai a sapere se è il tuo DB che ha fallito o la rete o il disco? Guardando tra i registri vedrai sicuramente il tuo utilissimo messaggio di debug, ma il codice ha bisogno di quelle informazioni lì e quindi, e il tipo di eccezione è lo strumento perfetto per questo.

Un'altra caratteristica che non hai menzionato è una gerarchia di eccezioni. Diverse implementazioni di un metodo possono generare eccezioni più specifiche. È anche più facile catturare un gruppo di eccezioni catturando la loro superclasse (fino a un certo punto, catch(Throwable e) è un antipattern).

Infine: se crei la tua gerarchia, non hai scontri. Nell'esempio più semplice in cui è necessario fornire un messaggio significativo quando un oggetto non viene trovato, sarebbe piuttosto imbarazzante dare un messaggio che dice "Impossibile trovare l'oggetto: l'oggetto non può essere aggiunto all'elenco" perché è stato effettivamente lanciato da una% metodoList.add(e), non il tuo metodo ...

    
risposta data 03.07.2014 - 17:26
fonte

Leggi altre domande sui tag