Início / coding / Perguntas / 78901654
Accepted
Javier
Asked: 2024-08-22 20:46:50 +0800 CST

O relançamento em multi-catch está formalmente definido? [duplicado]

  • 772

Por que é throw epermitido, mas não throw a, no seguinte caso?

  void test() {
    try {
      System.out.println();
    } catch (Error | RuntimeException e) {
      var a = e;
      //throw a; unreported exception Throwable; must be caught or declared to be thrown
      throw e;
    }
  }

Tudo isso intuitivamente faz sentido, mas a partir do JLS 14.20

Uma cláusula multi-catch pode ser considerada uma sequência de cláusulas uni-catch. Ou seja, uma cláusula catch onde o tipo do parâmetro de exceção é denotado como uma união D1|D2|...|Dné equivalente a uma sequência de n cláusulas catch onde os tipos dos parâmetros de exceção são tipos de classe D1, D2, ..., Dnrespectivamente. No bloco de cada uma das n cláusulas catch, o tipo declarado do parâmetro de exceção é lub(D1, D2, ..., Dn).

Como lub(Error,RuntimeException)is Throwable, o código acima deve ser equivalente a:

    try {
      System.out.println();
    } catch (Error e) {
      Throwable lub = e;
      throw lub;
    } catch (RuntimeException e) {
      Throwable lub = e;
      throw lub;
    }

(que obviamente não compila)

Além disso, o tipo de aé o tipo de e"quando tratado como se não aparecesse em um contexto de atribuição" ( JLS 14.4.1 ), mas como mostrado acima não é o mesmo que o tipo de e.

Há algo que eu esqueci?

Editar : esta não é uma duplicata de Por que é legal lançar novamente um Throwable em certos casos, sem declará-lo? porque esta questão é específica para multi-catch (que não é discutida lá) e surge devido a um mal-entendido de um fragmento específico do JLS que aborda multi-catch. As respostas fornecidas nesta pergunta me ajudaram a ligar os pontos :)

java

3 respostas

  1. Best Answer

    Isso é descrito em 11.2.2 . Isso basicamente se resume a "parâmetros de exceção catch (...)são um caso especial".

    Nosso objetivo é mostrar throw e;compilações. Começamos com esta linha em 11.2.3:

    É um erro em tempo de compilação se um método ou corpo de construtor puder lançar alguma classe de exceção E quando E for uma classe de exceção verificada e E não for uma subclasse de alguma classe declarada na cláusula throws do método ou construtor.

    Então, queremos mostrar que a tryinstrução in testnão pode ser lançada Throwable. Observe que “pode lançar” neste contexto é um termo rigorosamente definido. De acordo com 11.2.2,

    Uma instrução try pode lançar uma exceção de classe E se:

    • O bloco try pode lançar E, [...]

    • Algum bloco catch da instrução try pode lançar E e nenhum bloco final está presente ou o bloco final pode ser concluído normalmente; ou

    • Um bloco final está presente e pode lançar E.

    Apenas o segundo ponto é relevante aqui. Vamos mostrar que o catchbloco não pode ser lançado Throwable. Ou seja, throw e;não pode lançar Throwable.

    Uma instrução throw cuja expressão lançada é um parâmetro de exceção final ou efetivamente final de uma cláusula catch C pode lançar uma classe de exceção E se:

    • E é uma classe de exceção que o bloco try da instrução try que declara C pode lançar; e

    • E é atribuição compatível com qualquer uma das classes de exceção capturáveis ​​de C; e

    • E não é compatível com nenhuma das classes de exceção capturáveis ​​das cláusulas catch declaradas à esquerda de C na mesma instrução try.

    throw e;aqui falha imediatamente o primeiro ponto, então podemos concluir que throw e;não é possível lançar Throwable.

    Se fosse throw a;, então o acima não se aplica, mas outra cláusula se aplica:

    Uma instrução throw cuja expressão lançada tem tipo estático E e não é um parâmetro de exceção final ou efetivamente final pode lançar E ou qualquer classe de exceção que a expressão lançada possa lançar.

    • 6

  2. O compilador Java é inteligente o suficiente para reconhecer que capturar ee lançar esignificará lançar RuntimeExceptionou Errore, portanto, não uma exceção verificada que não foi declarada.

    Por outro lado, o tipo de var aé inferido Throwable(e não Error | RuntimeExceptioncomo você pode pensar, já que tal declaração não é realmente válida nesse contexto!) e, portanto, throw asignifica que você lança um Throwablee, portanto, o compilador não sabe com certeza você não está lançando uma exceção verificada e, como tal, gera o erro.

    O compilador poderia ser alterado para reconhecer isso? Provavelmente sim. Faria sentido fazer isso? Provavelmente não (ou pelo menos o valor de fazer provavelmente não vale o investimento).

    Isto segue as regras especificadas em 14.18 A throwDeclaração combinada com 11.2.2 Análise de Exceções de Declarações .

    Segue especificamente desta regra em 11.2.2 para throw e:

    Uma throwinstrução cuja expressão lançada é um parâmetro de exceção final ou efetivamente final de uma catchcláusula C pode lançar uma classe de exceção E se:

    • E é uma classe de exceção que o bloco try da instrução try que declara C pode lançar; e
    • E é atribuição compatível com qualquer uma das classes de exceção capturáveis ​​de C; e
    • E não é compatível com nenhuma das classes de exceção capturáveis ​​das cláusulas catch declaradas à esquerda de C na mesma instrução try.

    Por outro lado, para throw a, aplica-se o seguinte:

    Uma instrução throw ( §14.18 ) cuja expressão lançada tem tipo estático E e não é um parâmetro de exceção final ou efetivamente final pode lançar E ou qualquer classe de exceção que a expressão lançada possa lançar.

    • 4

  3. A parte saliente do JLS é 11.2.2 que diz:

    Uma throwinstrução cuja expressão lançada é um finalparâmetro de exceção efetivamente final de uma cláusula catch C pode lançar uma classe de exceção E se:

    • E é uma classe de exceção que o bloco try da tryinstrução que declara C pode lançar; e

    • E é atribuição compatível com qualquer uma das classes de exceção capturáveis ​​de C; e

    • ...

    Isso explica por que o seguinte irá lançar um Errorou RuntimeException:

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

    Mas no seguinte:

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

    o tipo inferido aé Throwable(o limite superior). E isso resultará em um erro de compilação... se o método envolvente não for declarado como throw Throwable.

    Para a vardeclaração, JLS 14.4.1 diz o seguinte:

    Se LocalVariableType for var, então seja T o tipo da expressão inicializadora quando tratada como se não aparecesse em um contexto de atribuição e, portanto, fosse uma expressão autônoma (§15.2). O tipo da variável local é a projeção ascendente de T em relação a todas as variáveis ​​de tipo sintético mencionadas por T (§4.10.5).

    Isso é difícil de analisar, mas meu entendimento é que "a projeção ascendente de T" é o mesmo tipo conhecido como "limite superior mínimo". No test2exemplo seria Throwable.

    Observe que o texto JLS que você citou em sua pergunta é um texto ilustrativo e não normativo. E não descreve o que acontece quando você (re) lança a exceção capturada.

    • 2

relate perguntas