Lancio di un'eccezione non definita nell'interfaccia

Question

Qual è la procedura migliore da seguire quando è necessario generare un'eccezione non 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, si dispone di una specifica deroga che si verifica quando la lettura di dolcetti, così si vuole lanciare un'eccezione relative a questo. Tuttavia, Reader non definisce questo tipo di eccezione nella sua interfaccia, quindi cosa fai? Inoltre, non ha senso aggiungere CupcakeException al tiri clausola del Reader interfaccia , perché questo tipo di eccezione è specifico per CupcakeReader. Un modo per aggirare questo è quello di definire leggere in modo tale che genera un tipo genitore, come Eccezione, ma poi si perde il contesto per l'eccezione. Cosa dovresti fare in questa situazione? Grazie!

---

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

A scopo illustrativo, qui è 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 vuole indicare che un problema si è verificato in CupcakeReader s' leggere metodo.

Answer 1

Potrebbe essere necessario creare un'eccezione del tipo previsto.

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

Answer 2

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

Answer 3

Utilizzare qualcosa chiamato ReaderException che fungerà da interfaccia principale della gerarchia di eccezioni. ReaderException fornisce anche un collegamento ad altre eccezioni che vengono generate a causa di eccezioni di livello inferiore.

Answer 4

Se si crea una maggiore un'eccezione astratto che funziona come una classe base per CupCakeException non si associa l'interfaccia del lettore ad una specifica applicazione, come si sarebbe fare se si è aggiunto il CupCakeException all'interfaccia Reader. Se non si eredita un'eccezione da un altro, c'è un constructor nella classe di eccezioni che accetta un throwable come secondo argomento come Thorbjørn Ravn Andersen ha già mostrato nel suo esempio di codice breve. Ti consente di generare un'eccezione più astratta e ogni parte del tuo codice che deve sapere di più, solo che "c'è un errore" può cercare la causa dell'eccezione più alta.

Answer 5

Basta non utilizzare le eccezioni controllate.

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

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

Così, invece di:

Value value = reader.read(); 

Lo costringono a fare questo:

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

value.doSomething(); // potential NPE here 

Pensate che uno è migliore, più leggibile e meno soggetta ad errori e solo smettere di usare eccezioni controllate.

EDIT:

Sono sorpreso con il rating negativo. Ci sono persone che pensano ancora che le eccezioni controllate siano grandi? Se è così ecco alcuni riferimenti per cui non si dovrebbe usare eccezioni controllate:

eccezioni

• No quadro moderno utilizza controllato (primavera, EJB3 ecc)
• articolo con esempi di codice here
• StackOverflow topic
• Efficace Java (sezioni 58 e 59) - here

Answer 6

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

È inoltre possibile rendere CupcakeException un figlio di IOException.