Определён ли формальный повторный забрасывание при многократной ловле?

Компилятор Java достаточно умен, чтобы распознать, что перехват e и выброс e будет означать, что вы выбрасываете RuntimeException или Error, и, следовательно, это не проверяемое исключение, которое не объявлено.

С другой стороны, тип var a выводится для Throwable (а не для Error | RuntimeException, как вы можете подумать, поскольку такое объявление на самом деле недействительно в этом контексте!), и, таким образом, throw a означает, что вы бросаете Throwable, и поэтому компилятор не знает наверняка, что вы не генерируете проверенное исключение, и поэтому вызывает ошибку.

Можно ли изменить компилятор, чтобы признать это? Наверное, да. Имеет ли смысл это сделать? Вероятно, нет (или, по крайней мере, ценность действий, вероятно, не стоит вложений).

Это следует из правил, указанных в 14.18 Оператор throw в сочетании с 11.2.2 Анализ исключений операторов.

В частности, это следует из этого правила в 11.2.2 для throw e:

Утверждение throw, бросаемое выражение которого является окончательным или фактически последний параметр исключения предложения catch C может вызвать исключение класс E, если:

• E — это класс исключений, который может генерировать блок try инструкции try, объявляющей C; и
• E является присваиванием, совместимым с любым из перехватываемых классов исключений C; и
• E не совместим по присваиванию ни с одним из перехватываемых классов исключений предложений catch, объявленных слева от C в той же попытке. заявление.

С другой стороны, для throw a применимо следующее:

Оператор throw (§14.18), чье выброшенное выражение имеет статический тип E и не является окончательным или фактически окончательным параметром исключения, может выдать E или любой класс исключения, который может выдать выброшенное выражение.

Важной частью JLS является 11.2.2, в котором говорится:

Утверждение throw, бросаемое выражение которого представляет собой final или эффективно последний параметр исключения в предложении catch C может выдать исключение класс E, если:

• E — это класс исключения, который может выдать блок try оператора try, объявляющего C; и

• E является присваиванием, совместимым с любым из перехватываемых классов исключений C; и

• ...

Это объясняет, почему следующие команды выбрасывают либо Error, либо RuntimeException:

  void test1() {
    try {
      ...
    } catch (Error | RuntimeException e) {
      throw e;
    }
  }

Но в следующем:

  void test2() {
    try {
      ...
    } catch (Error | RuntimeException e) {
      var a = e;
      throw a;
    }
  }

предполагаемый тип a — это Throwable (верхняя граница). И это приведет к ошибке компиляции... если включающий метод не объявлен как бросающий Throwable.

Для объявления varJLS 14.4.1 говорит следующее:

Если LocalVariableType равен var, то пусть T будет типом выражения инициализатора, если рассматривать его так, как если бы оно не появлялось в контексте присваивания и, таким образом, было автономным выражением (§15.2). Тип локальной переменной — это проекция T вверх по отношению ко всем переменным синтетического типа, упомянутым T (раздел 4.10.5).

Это сложно разобрать, но я понимаю, что «проекция Т вверх» — это тот же тип, который называется типом «наименьшей верхней границы». В примере test2 это будет Throwable.

Обратите внимание, что текст JLS, который вы процитировали в своем вопросе, является иллюстративным, а не нормативным. И он не описывает, что происходит, когда вы (повторно) выбрасываете перехваченное исключение.

Это описано в 11.2.2. По сути, это сводится к тому, что «параметры исключения в catch (...) являются особым случаем».

Наша цель — показать throw e; компиляции. Мы начинаем с этой строки в 11.2.3:

Это ошибка времени компиляции, если тело метода или конструктора может выдать некоторый класс исключения E, когда E является проверенным классом исключений и E не является подклассом какого-либо класса, объявленного в предложении throws метода или конструктора.

Итак, мы хотим показать, что оператор try в test не может выбрасывать Throwable. Обратите внимание, что «может бросить» в этом контексте — это строго определенный термин. Согласно 11.2.2,

Оператор try может вызвать исключение класса E, если:

• Блок try может выдать E, [...]

• Некоторый блок catch оператора try может выдать E, и либо блокfinally отсутствует, либо блокfinally может завершиться нормально; или

• Блок «finally» присутствует и может выдать E.

Здесь важен только второй пункт. Давайте покажем, что блок catch не может выбросить Throwable. А именно throw e; не может бросить Throwable.

Оператор throw, выражение которого является окончательным или фактически последний параметр исключения в предложении catch C может выдать исключение класс E, если:

• E — это класс исключений, который может генерировать блок try инструкции try, объявляющей C; и

• E является присваиванием, совместимым с любым из перехватываемых классов исключений C; и

• E не совместим по присваиванию ни с одним из перехватываемых классов исключений предложений catch, объявленных слева от C в той же попытке. заявление.

throw e; здесь сразу же не соответствует первому пункту, поэтому мы можем сделать вывод, что throw e; не может бросить Throwable.

Если бы это было throw a;, то вышеизложенное не применимо, но применимо другое предложение:

Оператор throw, чье выброшенное выражение имеет статический тип E и не является окончательным или фактически окончательным параметром исключения, может выдать E или любой класс исключения, который может выдать выброшенное выражение.