Pourquoi la modification de la variable retournée dans un bloc finally ne change-t-elle pas la valeur de retour?

J'ai une classe Java simple comme indiqué ci-dessous:

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

Et la sortie de ce code est la suivante:

Entry in finally Block
dev  

Pourquoi n'est-il spas remplacé dans le finallybloc, tout en contrôlant la sortie imprimée?

Le trybloc se termine par l'exécution de l' returninstruction et la valeur de sau moment où l' returninstruction s'exécute est la valeur renvoyée par la méthode. Le fait que la finallyclause modifie ultérieurement la valeur de s(une fois l' returninstruction terminée) ne modifie pas (à ce stade) la valeur de retour.

Notez que ce qui précède traite des modifications de la valeur de slui - même dans le finallybloc, pas de l'objet qui fait sréférence. Si sétait une référence à un objet mutable (ce qui Stringne l'est pas) et que le contenu de l'objet était modifié dans le finallybloc, alors ces modifications seraient vues dans la valeur renvoyée.

Les règles détaillées sur la façon dont tout cela fonctionne se trouvent dans la section 14.20.2 de la spécification du langage Java . Notez que l'exécution d'une returninstruction compte comme une fin brusque du trybloc (la section commençant " Si l'exécution du bloc try se termine brusquement pour toute autre raison R .... " s'applique). Voir la section 14.17 du JLS pour savoir pourquoi une returninstruction est une fin brusque d'un bloc.

À titre de détail supplémentaire: si le trybloc et le finallybloc d'une try-finallyinstruction se terminent brusquement à cause d' returninstructions, les règles suivantes du §14.20.2 s'appliquent:

Si l'exécution du trybloc se termine brusquement pour toute autre raison R [en plus de lancer une exception], alors le finallybloc est exécuté, puis il y a un choix:

• Si le finallybloc se termine normalement, l' tryinstruction se termine brusquement pour la raison R.
• Si le finallybloc se termine brusquement pour la raison S, alors l' tryinstruction se termine brusquement pour la raison S (et la raison R est rejetée).

Le résultat est que l' returninstruction dans le finallybloc détermine la valeur de retour de l' try-finallyinstruction entière et la valeur renvoyée du trybloc est ignorée. Une chose similaire se produit dans une try-catch-finallyinstruction si le trybloc lève une exception, il est intercepté par un catchbloc et le catchbloc et le finallybloc ont des returninstructions.

Parce que la valeur de retour est placée sur la pile avant l'appel de finally.

Si nous regardons à l'intérieur du bytecode, nous remarquerons que JDK a fait une optimisation significative et que la méthode foo () ressemble à:

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

Et 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 a préservé la chaîne "dev" d'être modifiée avant de revenir. En fait, il n'y a finalement aucun blocage du tout.

Il y a 2 choses à noter ici:

• Les chaînes sont immuables. Lorsque vous définissez s sur "override variable s", vous définissez s pour qu'il fasse référence à la chaîne en ligne, sans modifier le tampon de caractères inhérent de l'objet s pour le remplacer par "override variable s".
• Vous mettez une référence au s sur la pile pour revenir au code appelant. Ensuite (lorsque le bloc finally s'exécute), la modification de la référence ne devrait rien faire pour la valeur de retour déjà sur la pile.

Je change un peu votre code pour prouver le point de Ted.

Comme vous pouvez le voir, la sortie sest en effet modifiée mais après le retour.

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

Production:

Entry in finally Block 
dev 
override variable s

Techniquement parlant, le returndans le bloc try ne sera pas ignoré si un finallybloc est défini, seulement si ce bloc finally inclut également un return.

C'est une décision de conception douteuse qui était probablement une erreur rétrospectivement (un peu comme les références pouvant être annulées / mutables par défaut et, selon certains, vérifiées). À bien des égards, ce comportement est exactement cohérent avec la compréhension familière de ce que finallysignifie - «peu importe ce qui se passe au préalable dans le trybloc, exécutez toujours ce code». Par conséquent, si vous retournez vrai à partir d'un finallybloc, l'effet global doit toujours être à return s, non?

En général, c'est rarement un bon idiome, et vous devriez utiliser finallygénéreusement des blocs pour nettoyer / fermer les ressources, mais rarement, voire jamais, en renvoyer une valeur.

Essayez ceci: Si vous souhaitez imprimer la valeur de remplacement de s.

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