modo migliore per definire un'eccezione generata da un metodo in Java?

Presumo che ci siano situazioni in cui ragionevole genera eccezioni.

Inoltre assumerò che questo sia una situazione in cui ragionevole usi le eccezioni. (Il fatto che questo sia "interno" al tuo codice non altera questo e non puoi ragionevolmente dedurre che le eccezioni siano appropriate in base al nome dell'eccezione proposto ... @Jarrod Roberson note!)

Quindi la domanda è se sia ragionevole dichiarare una classe di eccezione private . A questo direi "Sì", partendo dal presupposto che non esiste una classe di eccezioni valida.

Gli unici corridori che vorrei fare è che se c'è qualche possibilità che l'eccezione possa "perdere", allora:

• dovresti dichiarare un costruttore in modo che l'eccezione abbia una ragione String e
• dovresti dichiararlo come public ... in modo che qualsiasi javadoc per l'eccezione venga visualizzato nella documentazione dell'API pubblicata.

Le eccezioni non riguardano errori che possono essere ragionevolmente controllati. Inoltre, non sono sicuro del motivo per cui definisci un tipo di eccezione privata poiché non sarai in grado di rilevare tale eccezione mentre si propaga. Non sono nemmeno sicuro del motivo per cui stai creando una classe interiore.

L'estensione di RuntimeException, Exception o Throwable non riguarda il comportamento di override. Si tratta di creare una gerarchia di eccezioni appropriata per la tua applicazione. Ad esempio, se stai guidando una macchina, un'eccezione di basso livello potrebbe essere GPSReadError che è un tipo di NavigationError, che è un tipo di AutoDriveError che è un tipo di VehicleException. Si tratta anche di identificare la fonte dell'eccezione. Ad esempio, un GPSReadError non verrebbe utilizzato quando si controlla la pressione dei pneumatici.

Le eccezioni IMHO sono un'area in cui Java può essere ripulito, con framework come le sottoclassi di lancio primaverile di RuntimeException quasi esclusivamente. In effetti, è possibile esaminare l'uso intelligente di RuntimeExceptions da parte di Spring per classificare meglio gli errori quando si utilizza JDIBC. link

L'autore di Rod Johnson di Progettazione e sviluppo J2EE esperti menzionato eccezioni di runtime è spesso un'alternativa migliore alle eccezioni controllate (ovviamente molte cose dipendono dalla logica aziendale e dai membri del team).

Ma piuttosto

private class MissingPropertyException extends RuntimeException{};

puoi usare / progettare qualcosa di simile a NestedRuntimeException

Gli altri hanno tenuto lezioni sul corretto utilizzo delle eccezioni, quindi, invece di ripeterlo, suggerirei un'alternativa sotto forma di qualcosa chiamato opzionale :

Optional<String> optionalProperty = myMethod();
if (optionalProperty.isPresent())
   // do something with it
else
   // property did not exist

Questo approccio costringe il codice chiamante a intraprendere un'azione nel caso in cui il valore di ritorno sia mancante. Questo è analogo all'utilizzo di throws MissingPropertyException che costringe anche il chiamante a gestirlo, ma penso che l'uso di Opzionale sia più esplicito.

Va bene creare una sottoclasse di eccezione "vuota". Basta vederlo come una classificazione.

Mi attengo comunque a YAGNI e cerco sempre il codice che potrebbe effettivamente filtrare il tipo di eccezione che crei.

Side stepping tutti gli argomenti "should" e "should not" (che sono rilevanti, btw) .. se alla fine si finisce con una "inner class", almeno renderla "statica":

private static class MissingPropertyException extends RuntimeException{};

Se capisco il tuo utilizzo, prenderei in considerazione l'utilizzo di una "IllegalStateException" per questo con un buon messaggio. È già integrato in Java.

I motivi per cui hai scelto un'eccezione non controllata non mi sono chiari, ma penso che avrebbe senso sul metodo build () di un Schema generatore se il costruttore richiede l'utilizzo di uno dei numerosi parametri possibili. Controlla il tuo ragionamento per l'utilizzo di un'eccezione non controllata contro il mio post sul blog su verificato vs eccezioni non controllate .