Lanzar una excepción no definida en la interfaz

Question

¿Cuál es la mejor práctica a seguir cuando necesita lanzar una excepción que no estaba definida en una interfaz que está implementando?

Aquí se muestra un ejemplo:

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 {} 
} 

En este caso, usted tiene una excepción específica que se produce cuando la lectura de pastelitos, por lo que desea lanzar una excepción en relación con esto. Sin embargo, Reader no define este tipo de excepción en su interfaz, entonces, ¿qué hace usted? Por otra parte, no tiene sentido para añadir CupcakeException a la tiros cláusula en la interfaz del lector , porque este tipo de excepción es específico para CupcakeReader. Una forma de evitar esto es tener Lector definir leer de manera que arroje algún tipo parental, como Excepción, pero luego pierde el contexto de la excepción. ¿Qué deberías hacer en esta situación? ¡Gracias!

---

Otra situación interesante que se ha planteado implica una interfaz sobre la que no tiene control. En este caso, ¿cuál es la mejor manera de indicar que ha ocurrido un problema?

Para fines ilustrativos, aquí es otro ejemplo:

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

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

En este caso, no se puede cambiar lector, pero desea indicar que ha ocurrido un problema en CupcakeReader 's leer método.

Answer 1

En su lugar, debe crear una excepción del tipo esperado.

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

Answer 2

Quizás podría hacer una clase abstracta ReaderSpecificException, ponerla en la interfaz y subclase CupcakeException de esta clase abstracta.

Answer 3

Use algo llamado ReaderException que servirá como la interfaz raíz de su jerarquía de excepciones. ReaderException también proporciona un enlace a otras excepciones que se lanzan debido a excepciones de nivel inferior.

Answer 4

Si crea una excepción abstracta superior que funciona como una clase base para CupCakeException no asociar la interfaz del lector a una aplicación específica como la que estaría haciendo si se ha añadido la CupCakeException a la interfaz del lector. Si no dejas que una Excepción herede de otra, hay una constructor en la clase de excepción que toma un throwable como segundo argumento como Thorbjørn Ravn Andersen mostrado en su ejemplo de código corto. Le permite generar una excepción más abstracta y cada parte de su código que necesita saber más que solo "hay un error" puede buscar la causa de la excepción más alta.

Answer 5

Simplemente no use excepciones marcadas.

El ejemplo que mostró es uno de los motivos por los que las excepciones comprobadas son malas.

La razón principal es que el usuario de su lector de cupcake tendrá que manejar su excepción, independientemente de si le interesa o no.

Así que en lugar de:

Value value = reader.read(); 

Usted lo está obligando a hacer esto:

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

value.doSomething(); // potential NPE here 

Piense cuál es mejor, más fácil de leer y menos propenso a errores y simplemente deja de usar excepciones comprobadas.

EDIT:

Estoy sorprendido con la calificación negativa. ¿Hay personas que todavía piensan que las excepciones marcadas son excelentes? Si es así aquí hay algunas referencias por las que no debe utilizar excepciones comprobadas:

excepciones

• Ningún marco moderna utiliza controladas (primavera, EJB3 etc)
• artículo con ejemplos de código here
• Stackoverflow topic
• eficaz Java (secciones 58 y 59) - here

Answer 6

La excepción forma parte de la interfaz. Defina un padre genérico para todas sus excepciones en la interfaz si puede redefinir la interfaz.

También puede hacer que CupcakeException sea un elemento secundario de IOException.