Java: ¿Cuál es la forma correcta de declarar un método de interfaz que puede arrojar una excepción?

Question

Let decir que tengo esta interfaz A que es implementada por múltiples proveedores:

interface A 
{ 
    void x(); 
    void y(); 
} 

Sin embargo, quiero proveedores sean capaces de lanzar excepciones para señalar que algo ha fallado y, potencialmente, el método podría lanzado una RuntimeException. En cada caso, el código que llama a estos métodos debe manejar el error y continuar. Solo porque un vendedor arroja un NPE, no quiero que el sistema se caiga. En lugar de dejar en manos de la persona que llama el método (o en realidad por el propio mantenimiento de línea), me gustaría para asegurarse de que cada llamada capturar todas las excepciones al declarar cada método como:

void x() throws Exception; 

pero esto es generalmente mal práctica (al PMD no le gusta y, en general, estoy de acuerdo con la regla de los métodos concretos), entonces me pregunto si esto es una excepción a la regla o si hay una forma mejor.

Déjenme ser claro, estoy buscando una solución donde la persona que llama de la interfaz se ve obligada a manejar todas las excepciones (incluyendo RuntimeException s).

Para detallar más mi entorno, todo esto se ejecuta dentro de un marco OSGi. Entonces, cada proveedor empaqueta su código en un paquete y OSGi manejará todas las excepciones para evitar que todo el sistema se cuelgue. Lo que realmente estoy buscando son las interfaces de servicio OSGi que serán llamadas por algunos paquetes centrales. Lo que quiero asegurar es que cuando repito todos los servicios, un servicio no lanza un NPE y detiene el proceso que se está ejecutando. Quiero manejarlo de forma más elegante detectando todas las excepciones lanzadas desde el servicio para que los otros servicios proporcionados sigan administrándose.

Answer 1

Cree su propia clase de excepción, es decir. MySeviceException y tírelo desde la interfaz. La idea aquí es arrojar excepciones significativas, así que no tema crear muchas clases de excepciones personalizadas si eso proporciona la mayor legibilidad y facilidad de mantenimiento para sus propósitos. Puede ver las excepciones detalladas del proveedor en el proceso descendente y envolverlas como su excepción personalizada para que el flujo ascendente no tenga que ocuparse de las excepciones específicas del proveedor.

class MySeviceException extends Exception{ 
    public MySeviceException() {} 
    public MySeviceException(String msg) { super(msg); } 
    public MySeviceException(Throwable cause) { super(cause); } 
    public MySeviceException(String msg, Throwable cause) { super(msg, cause); } 
} 

interface A 
{ 
    void x() throws MySeviceExceptionException; 
    void y() throws MySeviceExceptionException; 
} 

Como regla general no coger Errors, siempre coger Exceptions y tratar con ella!

Answer 2

Los vendedores sin duda pueden lanzar RuntimeException al contenido de su corazón, porque están desmarcados. Eso significa que no tiene que agregar la cláusula throws a la interfaz.

También significa que los clientes no tendrán ninguna advertencia de la definición de la interfaz, y el compilador no aplicará un try/catch requerido. La única forma en que lo sabrán es leer tu Javadocss.

Puede crear una excepción personalizada que extienda java.lang.Exception; esa es una excepción marcada Tendrás que agregarlo a la cláusula throws; el compilador aplicará un try/catch alrededor de esos métodos; sus clientes tendrán que manejar el problema.

Answer 3

Evitaría colocar la excepción en la interfaz debido a las limitaciones que usted impone a los implementadores. Si debo lanzar una excepción implementando su interfaz, hará las maquetas para las pruebas más difíciles.

Si algo falla en el código que implementa su interfaz, esa debería ser la preocupación del programador de la clase implementadora.

Answer 4

La creación de una cláusula throws, incluso con un tipo de excepción personalizado, no es realmente una respuesta aquí. Siempre vas a tener cosas como NPE. Incluso si especifica a los proveedores que todas las excepciones deben estar envueltas en su tipo de excepción personalizado, habrá casos en los que alguien comete un error y se obtiene un NPE. Si no fuera por los errores, no tendrías NPEs.

Agregar "throws Exception" es una mala idea en muchos casos, pero en algunos casos funciona. En frameworks como Struts y JUnit puede agregar "throws Exception" (Excepción de tiradas) sin problemas porque el framework lo permite. (JUnit no sería muy útil si la primera excepción arrojó el paquete de prueba.)

Puede diseñar el sistema para que las llamadas al código del proveedor ocurran en módulos específicos que se conectan al sistema y que tienen excepciones. manejo manejado por el sistema, similar a cómo funcionan las acciones en Struts. Cada acción puede lanzar cualquier cosa, hay un controlador de excepción que registra lo que salió mal. De esta forma, la lógica comercial que llama a las API de los proveedores no debería verse afectada por la repetición inútil de las excepciones, pero si algo sale mal, el programa no se cierra.

Answer 5

Estoy de acuerdo con PMD - declarar que arroja genérico Exception s es feo. Creo que es mejor

• Definir nuevos, clases de excepción no en tiempo de ejecución específicos de dominio (si el built-in-one no lo harán, siempre se adhieren a clases predefinidas si coinciden con su semántica), y declarar en los métodos que pueden arrojarlos
• Mantenga las excepciones de tiempo de ejecución al mínimo. Solo tienen sentido cuando no tienes control sobre cómo te llaman, y nada más servirá. Si tiene alguna razón para esperar que los arrojen en un código que está llamando, entonces tóquelos tan pronto como tengan sentido y vuelva a lanzarlos como excepciones estándar (consulte el punto anterior).

Las versiones recientes de Java le permiten encadenar excepciones. Por ejemplo, si usted consigue un NullPointerException ex al analizar un File f con una biblioteca externa, que se quiere cogerlo y volver a lanzar como, por ejemplo, un new FileParsingException("error parsing " + f + ": " + ex.getMessage(), ex);

Answer 6

Dependiendo de la configuración de JVM, cualquier método tiene la capacidad de lanzar una RuntimeException si lo declaras como arrojando Exception o no. La captura/manejo de RuntimeExceptions es generalmente una mala práctica. Si bien hay algunos casos limitados en los que este comportamiento podría ser necesario, RuntimeExceptions es principalmente un indicador de que hay algo mal con el código, en lugar del uso del producto. Por supuesto, un inconveniente importante de la captura de RuntimeExceptions (especialmente si los está ignorando) es que las cosas podrían estar explotando en su sistema y no tiene idea de que está sucediendo ... entonces, de repente, su sistema escupe completamente datos no válidos o bloqueos de cualquier otro motivo, lo que hace más difícil rastrear la causa raíz. tutorial

Ver Sun/Oracle acerca de las excepciones

http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

Para responder a la pregunta, a menos que sepa exactamente lo derivado de excepción que puede esperar a estar lanzando, estás Excepción de lanzamiento bastante atrapado, aunque ¿Tiene dudas importantes sobre la utilidad de arrojar la clase de Excepción genérica, a menos que solo le importe cerrar la sesión de seguimiento de la pila y tal que sepa que sucedió? Si intenta manejar robustamente la Excepción sin saber qué tipo de Excepción es, entonces probablemente no tendrá mucho éxito en manejarla adecuadamente o incluso lo suficientemente bien.

Answer 7

Puede implementar su interfaz en una clase abstracta que utiliza el patrón de método de plantilla para capturar y ajustar RuntimeExceptions con una excepción personalizada. Sin embargo, no hay forma de exigir que los proveedores usen la clase abstracta (que no sea la documentación).

class MySeviceException extends Exception{ 
    public MySeviceException() {} 
    public MySeviceException(String msg) { super(msg); } 
    public MySeviceException(Throwable cause) { super(cause); } 
    public MySeviceException(String msg, Throwable cause) { super(msg, cause); } 
} 

interface A 
{ 
    void x() throws MySeviceExceptionException; 
    void y() throws MySeviceExceptionException; 
} 

class ABase implements A 
{ 
    public final void x() throws MySeviceExceptionException { 
     try { 
      doX(); 
     } catch(RuntimeException ex) { 
      throw new MySeviceExceptionException(ex); 
     } 
    } 
    public final void y() throws MySeviceExceptionException { 
     try { 
      doY(); 
     } catch(RuntimeException ex) { 
      throw new MySeviceExceptionException(ex); 
     } 
    } 

    public abstract void doX() throws MySeviceExceptionException; 
    public abstract void doY() throws MySeviceExceptionException; 
}