finallyブロックで返される変数を変更しても、戻り値が変更されないのはなぜですか？

以下に示すような単純なJavaクラスがあります。

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

そして、このコードの出力はこれです：

Entry in finally Block
dev  

なぜブロックでsオーバーライドされfinallyないのに、印刷出力を制御するのですか？

try実行とブロック完了returnの文との価値s時にreturn文の実行には、メソッドから返された値です。finally文節が後でs（returnステートメントの完了後に）値を変更するという事実は、（その時点で）戻り値を変更しません。

上記は、参照するオブジェクトではなくs、finallyブロック内の自身の値の変更を扱っていることに注意してsください。場合s変更可能なオブジェクトへの参照であった（これStringはない）、およびコンテンツオブジェクトのはで変更されたfinallyブロックは、これらの変更は、返された値に見られます。

これがどのように動作するかの詳細なルールは、Java言語仕様のセクション14.20.2にあります。returnステートメントの実行は、tryブロックの突然の終了としてカウントされることに注意してください（「tryブロックの実行が他の理由で突然完了した場合、R ....」が適用されます）。ステートメントがブロックの突然の終了である理由については、JLSのセクション14.17を参照してくださいreturn。

さらに詳しく言えば、ステートメントが原因でステートメントのtryブロックとブロックの両方が突然終了した場合、§14.20.2の次のルールが適用されます。finallytry-finallyreturn

tryブロックの実行が他の理由R（例外をスローする以外）で突然完了した場合、finallyブロックが実行され、次に選択肢があります。

• 場合はfinallyブロックが正常に完了し、その後、tryステートメントが理由で中途完了R.
• finallyブロックが理由Sで突然完了した場合、tryステートメントは理由Sで突然完了します（理由Rは破棄されます）。

その結果return、finallyブロック内のステートメントがステートメント全体の戻り値を決定し、ブロックtry-finallyからの戻り値tryは破棄されます。同じようなことはして発生しtry-catch-finallyた場合のステートメントtryブロックが例外をスローし、それがでキャッチされたcatchブロック、および両方のcatchブロックとfinallyブロックが持っているreturn文を。

なぜなら、戻り値は最終的にを呼び出す前にスタックに置かれるからです。

バイトコードの内部を見ると、JDKが大幅に最適化されており、foo（）メソッドは次のようになっていることがわかります。

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

そしてバイトコード：

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は、戻る前に「dev」文字列が変更されないようにしました。実際、ここでは最終的にはまったくブロックされません。

ここで注目すべき点が2つあります。

• 文字列は不変です。sを「override variable s」に設定する場合、sオブジェクトの固有のcharバッファーを変更して「override variable s」に変更しないで、インライン化されたStringを参照するようにsを設定します。
• スタック上のへの参照を入れて、呼び出し元のコードに戻ります。その後（finallyブロックが実行されるとき）、参照を変更しても、既にスタックにある戻り値に対して何も行わないはずです。

テッドのポイントを証明するために、コードを少し変更します。

あなたが見ることができるように、出力sは確かに変更されましたが、戻った後。

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

出力：

Entry in finally Block 
dev 
override variable s

技術的に言えreturnば、finallyブロックが定義されている場合、tryブロックのinは無視されませんreturn。最終的にブロックにが含まれている場合に限ります。

これは、おそらく振り返ってみると間違いである疑わしい設計上の決定です（参照がデフォルトでnull可能/変更可能であり、一部の例ではチェックされた例外と同様）。多くの点で、この動作は何をfinally意味するかについての口語的な理解と正確に一致しています-「tryブロック内で事前に何が発生しても、常にこのコードを実行してください」。したがって、finallyブロックからtrueを返す場合、全体的な効果は常にtoになる必要がありreturn sますか？

一般に、これはめったに良いイディオムではありません。finallyリソースをクリーンアップ/クローズするために自由にブロックを使用する必要がありますが、リソースから値を返すことはほとんどありません。

これを試してください：sのオーバーライド値を出力したい場合。

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