Generazione di un'eccezione non definita nell'interfaccia

Question

Qual è la migliore pratica da seguire quando è necessario generare un'eccezione che non è stata definita in un'interfaccia che si sta implementando?

Ecco un esempio:

public interface Reader
{
    public abstract void read() throws IOException;
}

public class CarrotReader implements Reader
{
    public void read() throws IOException {}
}

public class CupcakeReader implements Reader
{
    public void read() throws IOException, CupcakeException {}
}

In questo caso, hai un'eccezione specifica che si verifica durante la lettura di cupcake, quindi vuoi lanciare un'eccezione relativa a questo. Tuttavia, Reader non definisce questo tipo di eccezione nella sua interfaccia, quindi cosa fai? Inoltre, non ha senso aggiungere CupcakeException alla clausola lancia nell'interfaccia Reader , perché questo tipo di eccezione è specifico di < em> CupcakeReader . Un modo per aggirare questo problema è far sì che Reader definisca leggi in modo tale da generare un tipo di genitore, come Eccezione , ma si perde il contesto per eccezione. Cosa dovresti fare in questa situazione? Grazie!

---

Un'altra situazione interessante che è stata sollevata riguarda un'interfaccia su cui non hai alcun controllo. In questo caso, qual è il modo migliore per indicare che si è verificato un problema?

A scopo illustrativo, ecco un altro esempio:

public interface Reader
{
    public abstract void read();
}

public class CupcakeReader implements Reader
{
    public void read() throws CupcakeException {}
}

In questo caso, non è possibile modificare Reader , ma si desidera indicare che si è verificato un problema nel metodo leggi di CupcakeReader .

Answer 1

Potrebbe essere necessario invece creare un'eccezione del tipo previsto.

... catch(CupcakeException e) {
   throw new IOException("The sky is falling", e);
 }

Answer 2

Usa qualcosa chiamato ReaderException che fungerà da interfaccia principale della tua gerarchia di eccezioni. ReaderException fornirà inoltre un collegamento ad altre eccezioni generate a causa di eccezioni di livello inferiore.

Answer 3

L'eccezione fa parte dell'interfaccia. Definire un genitore generico per tutte le eccezioni nell'interfaccia se è possibile ridefinire l'interfaccia.

Puoi anche fare CupcakeException come figlio di IOException.

Answer 4

Basta non usare le eccezioni selezionate.

L'esempio che hai mostrato è uno dei motivi per cui le eccezioni controllate sono sbagliate.

Il motivo principale è che l'utente del tuo lettore di cupcake dovrà gestire la tua eccezione indipendentemente dal fatto che sia interessato o meno.

Quindi invece di:

Value value = reader.read();

Lo stai forzando a fare questo:

Value value = null;
try {
    value = reader.read();
} catch (Exception e) {
    // now what??
}

value.doSomething();   // potential NPE here

Pensa a quale è meglio, più leggibile e meno soggetto a errori e smetti di usare le eccezioni verificate.

Modifica

Sono sorpreso dal voto negativo. Ci sono persone che pensano ancora che le eccezioni verificate siano fantastiche? In tal caso, ecco alcuni riferimenti perché non dovresti usare le eccezioni selezionate:

• Nessun framework moderno utilizza eccezioni verificate (Spring, EJB3 ecc.)
• Articolo con esempi di codice qui
• StackOverflow topic
• Java efficace (sezioni 58 e 59) -

Answer 5

Forse potresti creare una classe ReaderSpecificException astratta, inserirla nell'interfaccia e sottoclasse CupcakeException da questa classe astratta.

Answer 6

Se crei un'eccezione astratta superiore che funziona come una classe base per CupCakeException, non associ l'interfaccia Reader a un'implementazione specifica come faresti se aggiungessi CupCakeException all'interfaccia Reader. Se non lasci che un'eccezione erediti da un'altra, c'è un costruttore nella classe d'eccezione che accetta un lancio come secondo argomento come Thorbj & # 248; Ravn Andersen ha già mostrato nel suo cortometraggio esempio di codice. Ti consente di generare un'eccezione più astratta e ogni parte del tuo codice che ha bisogno di sapere di più di un semplice "errore". può cercare la causa dell'eccezione più elevata.