Perché la modifica della variabile restituita in un blocco finally non modifica il valore restituito?

Ho una semplice classe Java come mostrato di seguito:

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 l'output di questo codice è questo:

Entry in finally Block
dev  

Perché snon viene ignorato nel finallyblocco, ma controlla l'output stampato?

Il tryblocco si completa con l'esecuzione returndell'istruzione e il valore sal momento dell'esecuzione returndell'istruzione è il valore restituito dal metodo. Il fatto che la finallyclausola in seguito cambi il valore di s(al returntermine dell'istruzione) non modifica (a quel punto) il valore di ritorno.

Si noti che quanto sopra riguarda le modifiche al valore di sse stesso nel finallyblocco, non all'oggetto a cui fa sriferimento. Se sfosse un riferimento a un oggetto mutabile (che Stringnon lo è) e il contenuto dell'oggetto fosse cambiato nel finallyblocco, tali cambiamenti sarebbero visibili nel valore restituito.

Le regole dettagliate su come funziona tutto questo sono disponibili nella Sezione 14.20.2 della specifica del linguaggio Java . Si noti che l'esecuzione di returnun'istruzione conta come una brusca terminazione del tryblocco (si applica la sezione che inizia " Se l'esecuzione del blocco try si completa bruscamente per qualsiasi altro motivo R .... "). Vedere la sezione 14.17 del JLS per il motivo per cui returnun'istruzione è una brusca interruzione di un blocco.

A titolo di ulteriore dettaglio: se sia il tryblocco che il finallyblocco di try-finallyun'istruzione terminano bruscamente a causa di returnistruzioni, si applicano le seguenti regole dal §14.20.2:

Se l'esecuzione del tryblocco viene completata bruscamente per qualsiasi altro motivo R [oltre a generare un'eccezione], il finallyblocco viene eseguito e quindi esiste una scelta:

• Se il finallyblocco si completa normalmente, l' tryistruzione si completa bruscamente per il motivo R.
• Se il finallyblocco si completa bruscamente per il motivo S, la tryfrase si completa bruscamente per il motivo S (e il motivo R viene scartato).

Il risultato è che l' returnistruzione nel finallyblocco determina il valore restituito dell'intera try-finallyistruzione e il valore restituito dal tryblocco viene scartato. Una cosa simile si verifica in try-catch-finallyun'istruzione se il tryblocco genera un'eccezione, viene catturato da un catchblocco e sia il catchblocco che il finallyblocco hanno returnistruzioni.

Perché il valore restituito viene messo nello stack prima della chiamata a finalmente.

Se guardiamo all'interno del bytecode, noteremo che JDK ha apportato un'ottimizzazione significativa e il metodo foo () assomiglia a:

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 ha preservato la modifica della stringa "dev" prima di tornare. In effetti qui non esiste alcun blocco finalmente.

Ci sono 2 cose degne di nota qui:

• Le stringhe sono immutabili. Quando si imposta s su "ignora variabile s", si imposta s in modo da fare riferimento alla stringa incorporata, senza alterare il buffer di caratteri inerente all'oggetto s per passare a "sovrascrivere variabile s".
• È stato inserito un riferimento a s nello stack per tornare al codice chiamante. Successivamente (quando viene eseguito il blocco finally), la modifica del riferimento non dovrebbe fare nulla per il valore di ritorno già nello stack.

Cambio un po 'il tuo codice per dimostrare il punto di Ted.

Come puoi vedere nell'output sè infatti cambiato ma dopo il ritorno.

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

Produzione:

Entry in finally Block 
dev 
override variable s

Tecnicamente parlando, il returnblocco in try non verrà ignorato se finallyviene definito un blocco, solo se quel blocco infine include anche a return.

È una decisione di progettazione dubbia che probabilmente è stata un errore in retrospettiva (molto simile ai riferimenti essendo nullable / mutable per impostazione predefinita e, secondo alcune, controllate le eccezioni). In molti modi questo comportamento è esattamente coerente con la comprensione colloquiale di ciò che finallysignifica - "qualunque cosa accada prima nel tryblocco, esegui sempre questo codice". Quindi, se si ritorna vero da un finallyblocco, l'effetto complessivo deve essere sempre return s, no?

In generale, questo è raramente un buon linguaggio, e dovresti usare i finallyblocchi liberamente per ripulire / chiudere le risorse ma raramente se mai restituire un valore da esse.

Prova questo: se vuoi stampare il valore di override di s.

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