2012-05-09 15 views
14

¿Puede alguien decirme qué razones excepciones pueden tener, por no ser compatibles con "tiros" cláusulas¿Cuáles son las razones para que las Excepciones no sean compatibles con las cláusulas throws?

Por ejemplo:

class Sub extends Super{ 

    @Override 
    void foo() throws Exception{ 

    } 

} 

class Super{ 

    void foo() throws IOException{ 

    } 
} 

Excepción Excepción no es compatible con cláusula throws en Super.foo()

+1

Por favor, muéstrenos el código completo que demuestra el problema. Incluyendo también el nombre de clase completamente calificado para su 'Excepción' (s). –

+1

¿Puedes mostrar un poco más de tu código y el error exacto que estás obteniendo? – aniri

+0

La mina funciona. Deberías mostrarnos más código que eso. – Averroes

Respuesta

22

Sin un ejemplo de código completo, solo puedo adivinar: está anulando/implementando un método en una subclase, pero la especificación de excepción del método de subclase no es compatible (es decir, no es un subconjunto) con la de la superclase/método de interfaz?

Esto puede ocurrir si se declara que el método base no arroja ninguna excepción, o p. java.io.IOException (que es una subclase de java.lang.Exception que su método está tratando de arrojar aquí). Los clientes de la clase/interfaz base esperan que sus instancias se adhieran al contrato declarado por el método base, por lo que lanzar Exception desde una implementación de ese método rompería el contrato (y LSP).

+0

Gracias Péter Török- Edición cerrada –

+0

I Sé que no es un sitio de discusión, pero no entiendo por qué LSP no permite ** agregar ** algo ...!? –

+6

Permite agregar algo. Pero cuando agrega un tipo de excepción a un método reemplazado, no está agregando algo, sino eliminando algo: con la clase base, nunca se obtendrá una excepción, pero con la subclase, se pierde esta garantía. Es por eso que está prohibido. –

-1

Las excepciones controladas están pensadas para su uso en situaciones donde un método puede esperar que su interlocutor esté preparado para tratar ciertos problemas que puedan surgir. Si los llamantes de BaseFoo.Bar() no están obligados a tratar con un FnordException, el método DerivedFoo.Bar() tampoco puede esperar que sus interlocutores se ocupen de un FnordException (ya que muchos de sus llamantes serán los mismos que no estaban preparados para tener BaseFoo.Bar() arrojándolo).

Conceptualmente, eso es genial. En la práctica, no tanto. El problema es que el diseño de las excepciones comprobadas en el lenguaje asume que o bien las personas que llamen no estarán preparadas para tratar con elegancia un problema en particular, o bien todas las personas que llamen estarán preparadas para enfrentarlo. En la práctica, el estado normal de las cosas es que las personas que llaman no están preparadas para lidiar con las excepciones, incluso aquellas que algunas personas que llaman podrían ser capaces de manejar. La mayoría de las veces, el curso de acción apropiado cuando el código recibe una excepción comprobada que no espera explícitamente sería envolverlo en una excepción sin marcar y arrojar eso. Irónicamente, el curso de acción más fácil - agregar una cláusula de "lanzamientos" y permitir que la excepción marcada suba, es probablemente la menos probable que sea correcta. Si bien hay algunos casos (por ejemplo, IOException) donde tal comportamiento tendría sentido (por ejemplo, al intentar leer una colección de un archivo, un error de E/S al leer un elemento es un error de E/S al leer la colección), La excepción lanzada desde una llamada a método anidado representará una condición diferente de la que tendrá una excepción del mismo tipo arrojado por el método externo, y el código que estaría preparado para manejar este último puede no estar preparado para manejar el primero.

En su situación, su mejor opción es capturar IOException y envolverlo en otro tipo que se deriva de RuntimeException, teniendo en cuenta que es poco probable que las personas que llaman puedan manejarlo.

-1

solucionarlo utilizar RuntimeException

public T findById(long id) throws RuntimeException { 
    try { 
      return whatEver.create(); 
    } catch (SystemException e) { 
      throw new RuntimeException(e); 
    } 
} 

Espero que esto ayude.

-1

Asegúrate de haber declarado throw en tu interfaz. Si lo hizo, pero el problema persiste, intente guardar/reconstruir el proyecto.

+0

No creo que este sea el camino a seguir. –

Cuestiones relacionadas