Declarar y lanzar contra lanzar sin excepciones

Question

En Java, ¿cuál es la diferencia entre los métodos gemelos?

public void methodA() throws AnException { 
    //do something 
    throw new AnException(); 
} 

public void methodA() { 
    //do the same thing 
    throw new AnException(); 
} 

tengo una intuición que tiene algo que ver con ser un método bien diseñado (porque puse MethodA en una interfaz, declaró que la forma MethodA * hace en su aplicación y recibido una advertencia de Java que "A * no puede anular A porque A * no arroja una excepción").

¿Es correcta esta especulación?

¿Hay alguna otra sutil connotación en las dos formas de hacer las cosas?

Answer 1

Si AnException es una excepción marcada (en otras palabras, si no extiende RuntimeException) entonces methodA no compilará. Las excepciones marcadas siempre deben ser desclasificadas.

Si AnException es una excepción sin marcar (si se extiende RuntimeException), entonces es permitido por el compilador java, y cualquiera de los dos es interpretado de manera equivalente por el tiempo de ejecución java. methodA todavía es probablemente todavía preferido en este caso, por las razones de la documentación. El javadoc para su método mostrará que podría lanzar AnException. Es bueno que los usuarios de su método sepan qué excepciones deben esperar.

Answer 2

En el segundo método, la clase AnException debe ser una subclase de RuntimeException, lo que significa que la declaración no es obligatoria y que los llamadores del método no tienen que manejarla. Un ejemplo de RuntimeException es ArrayOutOfBoundException, imagina si hubieras manejado explícitamente la excepción (al declarar un throws o con un bloque try/catch) cada vez que uses una lista.

Answer 3

Por razones puramente de documentación, es bueno que la excepción se incluya en la definición de la función. De esta manera, es claro para quienes llaman qué excepciones deben manejarse. También estoy adivinando que el compilador necesita realizar una configuración avanzada para las funciones que generan excepciones.

Answer 4

El primer método se debe invocar en try catch block o en el método que declara throws AnException de lo contrario la compilación fallará.

La segunda no tiene esa restricción

Answer 5

Aparte de las buenas respuestas dadas por otros sobre el compilability de sus métodos por sí mismos, no es la cuestión de la implementación de interfaces y métodos imperiosas de superclases.

La regla dice que puede sobrescribir/implementar un método, pero no puede declarar la excepción adicional a las declaradas por la firma del método original. Para entender esto, piensa en este ejemplo.

Digamos que usted está utilizando algún tipo de estructura de datos:

public abstract class AbstractBox { 
    public abstract void addItem(Item newItem); 
    public abstract void removeItem(Item oldItem); 
} 

Usted tiene su propia aplicación, pero decide declarar excepciones que no aparecen en la firma original:

public class MyBox extends AbstractBox { 
    public void addItem(Item newItem) throws ItemAlreadyPresentException {...} 
    public void removeItem(Item oldItem) throws NoSuchItemException {...} 
} 

Ahora consideremos este código genérico que maneja objetos de cuadro y recibe una instancia de MyBox:

public void boxHandler(AbstractBox box) { 
    Item item = new Item(); 
    box.removeItem(item); 
} 

Quien haya escrito este código no esperaba ninguna excepción, ni tenía la intención de manejar el implementador o las excepciones. Para evitar esto, el compilador no le permitirá declarar excepciones adicionales a las de la firma original.

Por supuesto, si usted maneja excepciones internamente ... bueno, el compilador será más que feliz para permitir que usted deje caer excepciones declaradas desde su firma ;-)

Espero que esto ayude ...

Yuval = 8-)