Java 7 - точное повторение с окончательным исключением

Question

В предыдущих версиях java перебрасывание исключения обрабатывалось как выбрасывание типа параметра catch.

Например:

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

В Java 7 вы можете быть более точным в отношении создаваемого исключения, если объявите исключение 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;
    }
}

Мой вопрос : В документах говорится, что мне нужно объявить Исключение final. Но если я этого не сделаю, приведенный выше код все еще компилируется и работает. Я что-то пропустил?

Ссылка:

Project Coin: мульти-улов и окончательное отбрасывание
Добавить более гибкую проверку для отклоненных исключений

Answer 1

Я верю Я видел твит от Джоша Блоха, в котором говорилось, что "последнее" ограничение было снято позднее. Я посмотрю, смогу ли я найти пост об этом, но я подозреваю, что просто любая ранняя документация, которую вы прочитали, теперь неточна.

РЕДАКТИРОВАТЬ: Я не могу найти точную запись "все изменилось", но в документации Java 7 показан пример с , а не , который является окончательным. Он говорит о том, что переменные исключения неявно неявно final, когда блок catch объявляет более одного типа, но это немного отдельно.

РЕДАКТИРОВАТЬ: Теперь я нашел источник моей путаницы, но это сообщение внутренней рассылки :( В любом случае, его не нужно объявлять как окончательное, но я считаю, что компилятор обрабатывает его как неявно final - точно так же, как в сценарии с несколькими уловами.

Answer 2

Причина, по которой обе компиляции состоят в том, что исключение в предложении uni catch, которое впоследствии не изменяется, является неявно конечным ( JLS 14.20 ).

Так что для вашего примера не скомпилировать,вам нужно каким-то образом изменить e, например:

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 3

Без финала все еще действует java. Вы просто теряете преимущество, будучи «точным».