Блок catch Java, исключение catch не является окончательным

Я проверяю новые функции Java SE7, и в настоящее время я нахожусь в этой точке:

http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html

что касается функции "поймать несколько", когда я наткнулся на это утверждение:

Примечание. Если блок catch обрабатывает несколько типов исключений, параметр catch неявно является окончательным. В этом примере параметр catch ex является окончательным, и поэтому вы не можете присвоить ему какие-либо значения в блоке catch.

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

Мне просто интересно, почему это хорошая вещь в первую очередь? Разве не было бы неправильным по существу модифицировать пойманное исключение, прежде чем я угадаю, что оно будет переброшено или, возможно, будет записано сообщение? Разве не должно быть механизмом создания создавать исключение, чтобы оно точно представляло, что должно?

Я никогда не видел, чтобы исключение было изменено в блоке catch. Может быть, кто-то скажет, что это полезно?

Ответ 1

Это почти так же, как аргументы метода:

Обычно вы не изменяете их, и многие согласны с тем, что их следует рассматривать как final (нужно ли писать final перед ними, это вопрос некоторых дебатов).

Но поскольку нет технических требований, которые говорят, что это должно быть final, язык дает вам выбор.

Лично я знаю, что нет веской причины модифицировать ссылку на исключение блокировки catch.

Ответ 2

Я не могу придумать убедительный вариант использования для модификации исключения в классическом предложении catch. Однако это не означает, что это должно быть запрещено. Особенно учитывая, что вы можете изменить переменную параметра. Если вы считаете это тревожным, у вас есть возможность объявить переменную исключения final.

С другой стороны, разрешение изменения в catch с несколькими исключениями будет означать возможность действительно причудливого и запутывающего кода, например:

  catch (IOException | NullPointerException ex) {
      ...
      ex = new IllegalArgumentException(...);
  }

Я представляю, что подумали дизайнеры, добавив ограничения в этом случае.

Но так или иначе, так определяется язык Java и с чем мы должны жить. Там не так много смысла обсуждать кажущиеся несоответствия... если вы не собираетесь разрабатывать и внедрять новый язык.

Ответ 3

Причина, по которой я могу придумать, чтобы обеспечить ее окончательное, - это производительность. Как только оценка улова начинается, окончательная неизменная ценность в механике оценки обеспечивает более быструю оценку всех уловов. Поскольку try-catch широко используется в любом Java-коде, предпочтительнее дизайн с наивысшей производительностью.

Исходя из вышесказанного, это означает улучшение производительности, которое влияет на большинство программ.

Ответ 4

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