ejemplo - text box java

Java 7-Retorno preciso con una excepción final

Question

En versiones anteriores de java, el reenvío de una excepción se trataba como el tipo de parámetro catch

Por ejemplo:

public static void test() throws Exception{
    DateFormat df = new SimpleDateFormat("yyyyMMdd");
    try {
        df.parse("x20110731");
        new FileReader("file.txt").read();
    } catch (Exception e) {
        System.out.println("Caught exception: " + e.getMessage());
        throw e;
    }
}

En Java 7, puede ser más preciso acerca de la excepción que se lanza, si declara la excepción final :

//(doesn''t compile in Java<7)
public static void test2() throws ParseException, IOException{
    DateFormat df = new SimpleDateFormat("yyyyMMdd");
    try {
        df.parse("x20110731");
        new FileReader("file.txt").read();
    } catch (final Exception e) {
        System.out.println("Caught exception: " + e.getMessage());
        throw e;
    }
}

Mi pregunta : Los documentos dicen que necesito declarar la Excepción final . Pero si no lo hago, el código anterior aún compila y funciona. ¿Me estoy perdiendo de algo?

Referencias:

Moneda del proyecto: captura múltiple y relanzamiento final.
Agregue una comprobación más flexible para las excepciones de devolución

Answer 1

La razón por la que ambos compilan es que una excepción en una cláusula de captura uni que no se modifica posteriormente es implícitamente final ( JLS 14.20 ).

Entonces, para que su ejemplo no se compile, necesita modificar e de alguna manera, por ejemplo:

public static void test2() throws ParseException, IOException {
    DateFormat df = new SimpleDateFormat("yyyyMMdd");
    try {
        df.parse("x20110731");
        new FileReader("file.txt").read();
    } catch (Exception e) {
        if (e instanceof ParseException) {
            e = new ParseException("Better message", 0);
        } else {
            e = new IOException("Better message");
        }
        System.out.println("Caught exception: " + e.getMessage());
        throw e; //does not compile any more
    }
}

Answer 2

Sin el final sigue siendo válido java. Solo pierdes el beneficio de que sea ''preciso''.

Answer 3

Creo que vi un tweet de Josh Bloch que decía que la restricción "final" se había levantado tarde. Veré si puedo encontrar una publicación al respecto, pero sospecho que es solo que cualquier documentación "temprana" que lea ahora es inexacta.

EDITAR: No puedo encontrar la publicación exacta de "ha cambiado", pero los estados de la documentación de Java 7 muestran un ejemplo que no es definitivo. Habla de que las variables de excepción son implícitamente finales cuando un bloque catch declara más de un tipo, pero eso es un poco separado.

EDITAR: Ahora he encontrado el origen de mi confusión, pero es una publicación interna de la lista de correo :( De todos modos, no tiene que declararse como final, pero creo que el compilador lo trata como implícitamente final, como en el Escenario de captura múltiple.