Funzione che genera eccezioni estendendo IllegalArgumentException

Question

Funzione che genera eccezioni estendendo IllegalArgumentException

#1 da (7 voti)
#2 da (1 voti)

1

Ho un blocco try / catch che assomiglia a questo:

try {
    geoms.add(convertLineToGeom(ln));
} catch(IllegalArgumentException e) {
    System.out.println("ligne n°" + counter + " : " + e.getMessage());
}

La mia funzione convertLineToGeom potrebbe lanciare diverse eccezioni che ho fatto io stesso, tutte estendendo IllegalArgumentException.

La domanda è, che è la migliore pratica (entrambi i codici funzionano) tra:

public static <E extends IllegalArgumentException> IGeomD2 convertLineToGeom(String ln) throws E {

E

public static IGeomD2 convertLineToGeom(String ln) throws IllegalArgumentException {

Mi sento come se la prima affermasse bene che la funzione non lancia IllegalArgumentException ma alcuni dei suoi figli .... Quindi qual'è il miglior errore di battitura?

functions java inheritance exceptions

posta Paul Lemarchand 23.10.2017 - 13:12

fonte

2 risposte

1

As yourself not which is the best to *throw* ... 
As yourself which is the most useful to *catch*!

Perché abbiamo più tipi di eccezioni? In modo che il codice che cattura possa gestirli in modo diverso.

Se tutto ciò che vuoi fare è mettere un messaggio sullo schermo e uccidere il programma morto, allora tutto ciò di cui hai bisogno è l'eccezione stessa.

Se vuoi che un codice sia in grado di catturare SomethingNastyHappenedButYouCanDoSomethingAboutItException, usa i valori che sono passati in quell'eccezione per capire come fare e poi fare qualcosa [utile] su di esso e poi permettere al programma di continuare - tutto senza che l'utente conosca qualsiasi su di esso - allora hai bisogno di tipi di Eccezione più complessi.

risposta data 23.10.2017 - 17:24

fonte

Leggi altre domande sui tag functions java inheritance exceptions

Dispatch dinamico da una stringa (Python) utilizzando le chiavi primarie incrementali sui dati del mondo reale

score 7 · Accepted Answer

Non è necessario forzare i chiamanti a utilizzare un'espressione di tipo complicata per questo scopo. Si aspettano di ottenere un IllegalArgumentException come al solito, e il fatto che tu fornisca sottoclassi utili di questo tipo standard non dovrebbe imporre ulteriori oneri al chiamante, dal momento che la normale catch(IllegalArgumentException) funziona ancora (che cos'è la sostituibilità, dopotutto).

L'unico motivo per esporre il fatto che stai usando sottoclassi sarebbe quando utilizzi più campi informativi rispetto allo standard message nelle eccezioni personalizzate. Ma anche in questo caso dovresti dichiarare esplicitamente throws PaulException piuttosto che un'espressione con una variabile di tipo, anche se hai più sottoclassi di PaulException .

La regola empirica è: dichiarare i tipi di ritorno (e sì, lanciare le eccezioni è una sorta di ritorno) solo con dettagli sufficienti che il chiamante può usare i campi di cui hanno bisogno.