Por que alterar a variável retornada em um bloco final não altera o valor de retorno?

Eu tenho uma classe Java simples, como mostrado abaixo:

public class Test {

    private String s;

    public String foo() {
        try {
            s = "dev";
            return s;
        } 
        finally {
            s = "override variable s";
            System.out.println("Entry in finally Block");  
        }
    }

    public static void main(String[] xyz) {
        Test obj = new Test();
        System.out.println(obj.foo());
    }
}

E a saída desse código é esta:

Entry in finally Block
dev  

Por que snão é substituído no finallybloco, ainda controla a saída impressa?

O trybloco é concluído com a execução da returninstrução e o valor de sno momento em que a returninstrução é executada é o valor retornado pelo método. O fato de a finallycláusula alterar posteriormente o valor de s(após a conclusão da returninstrução) não muda (nesse ponto) o valor de retorno.

Observe que o item acima lida com alterações no valor de ssi mesmo no finallybloco, não no objeto que faz sreferência. Se sfosse uma referência a um objeto mutável (o que Stringnão é) e o conteúdo do objeto fosse alterado no finallybloco, essas alterações seriam vistas no valor retornado.

As regras detalhadas de como tudo isso funciona podem ser encontradas na Seção 14.20.2 da Especificação da linguagem Java . Observe que a execução de uma returninstrução conta como um término abrupto do trybloco (a seção que inicia " Se a execução do bloco try for concluída abruptamente por qualquer outro motivo, R .... " se aplica). Consulte a Seção 14.17 do JLS para saber por que uma returninstrução é um encerramento abrupto de um bloco.

Por meio de mais detalhes: se o trybloco e o finallybloco de uma try-finallyinstrução terminam abruptamente devido a returninstruções, as seguintes regras do §14.20.2 se aplicam:

Se a execução do trybloco for concluída abruptamente por qualquer outro motivo R [além de gerar uma exceção], o finallybloco será executado e haverá uma opção:

• Se o finallybloco for concluído normalmente, a tryinstrução será concluída abruptamente pelo motivo R.
• Se o finallybloco for concluído abruptamente pelo motivo S, a tryinstrução será concluída abruptamente pelo motivo S (e o motivo R será descartado).

O resultado é que a returninstrução no finallybloco determina o valor de retorno de toda a try-finallyinstrução e o valor retornado do trybloco é descartado. O mesmo ocorre em uma try-catch-finallyinstrução se o trybloco lança uma exceção, é capturado por um catchbloco e o catchbloco e o finallybloco têm returninstruções.

Porque o valor de retorno é colocado na pilha antes da chamada finalmente.

Se olharmos dentro do bytecode, perceberemos que o JDK fez uma otimização significativa e o método foo () se parece com:

String tmp = null;
try {
    s = "dev"
    tmp = s;
    s = "override variable s";
    return tmp;
} catch (RuntimeException e){
    s = "override variable s";
    throw e;
}

E bytecode:

0:  ldc #7;         //loading String "dev"
2:  putstatic   #8; //storing it to a static variable
5:  getstatic   #8; //loading "dev" from a static variable
8:  astore_0        //storing "dev" to a temp variable
9:  ldc #9;         //loading String "override variable s"
11: putstatic   #8; //setting a static variable
14: aload_0         //loading a temp avariable
15: areturn         //returning it
16: astore_1
17: ldc #9;         //loading String "override variable s"
19: putstatic   #8; //setting a static variable
22: aload_1
23: athrow

java preservou a string "dev" antes de retornar. De fato, aqui não há finalmente um bloqueio.

Há duas coisas dignas de nota aqui:

• Strings são imutáveis. Quando você define s para "substituir a variável s", define s para se referir à String incorporada, não alterando o buffer de caracteres inerente do objeto s para alterar para "substituir a variável s".
• Você coloca uma referência aos s na pilha para retornar ao código de chamada. Depois (quando o bloco finalmente é executado), a alteração da referência não deve fazer nada pelo valor de retorno já existente na pilha.

Mudo um pouco o seu código para provar o ponto de vista de Ted.

Como você pode ver na saída sé realmente alterado, mas após o retorno.

public class Test {

public String s;

public String foo() {

    try {
        s = "dev";
        return s;
    } finally {
        s = "override variable s";
        System.out.println("Entry in finally Block");

    }
}

public static void main(String[] xyz) {
    Test obj = new Test();
    System.out.println(obj.foo());
    System.out.println(obj.s);
}
}

Resultado:

Entry in finally Block 
dev 
override variable s

Tecnicamente falando, o returnbloco try não será ignorado se um finallybloco for definido, apenas se esse bloco finalmente também incluir a return.

É uma decisão de projeto duvidosa que provavelmente foi um erro em retrospecto (bem como referências sendo anuláveis ​​/ mutáveis ​​por padrão e, de acordo com algumas, exceções verificadas). De muitas maneiras, esse comportamento é exatamente consistente com o entendimento coloquial do que finallysignifica - "não importa o que aconteça de antemão no trybloco, sempre execute esse código". Portanto, se você retornar verdadeiro de um finallybloco, o efeito geral sempre deve ser return s, não?

Em geral, esse raramente é um bom idioma, e você deve usar finallyblocos liberalmente para limpar / fechar recursos, mas raramente, se é que alguma vez, retorna um valor a partir deles.

Tente isto: Se você deseja imprimir o valor de substituição de s.

finally {
    s = "override variable s";    
    System.out.println("Entry in finally Block");
    return s;
}