Почему изменение возвращаемой переменной в блоке 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блоке, то эти изменения будут видны в возвращаемом значении.

Подробные правила того, как все это работает, можно найти в разделе 14.20.2 спецификации языка Java. . Обратите внимание, что выполнение returnоператора считается внезапным завершением tryблока (применяется раздел, начинающийся с « Если выполнение блока try завершается внезапно по любой другой причине R .... »). См. Раздел 14.17 JLS, чтобы узнать, почему returnоператор является внезапным завершением блока.

Более подробно: если как tryблок, так и finallyблок try-finallyоператора внезапно завершаются из-за returnоператоров, то применяются следующие правила из §14.20.2:

Если выполнение tryблока завершается преждевременно по какой-либо другой причине R [кроме выдачи исключения], тогда выполняется finallyблок, и тогда есть выбор:

• Если finallyблок завершается нормально, то tryоператор завершается преждевременно по причине R.
• Если finallyблок завершается внезапно по причине S, тоtry оператор завершается преждевременно по причине S (и причина R отбрасывается).

В результате returnоператор в finallyблоке определяет возвращаемое значение всего try-finallyоператора, а возвращаемое значение из tryблока отбрасывается. Подобное происходит в try-catch-finallyоператоре, если tryблок выдает исключение, он перехватывается catchблоком, и у catchблока и у finallyблока есть returnоператоры.

Потому что возвращаемое значение помещается в стек перед вызовом finally.

Если мы заглянем внутрь байт-кода, то заметим, что 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 для «переопределить переменную s», вы устанавливаете s для обращения к встроенной строке, не изменяя встроенный буфер символов объекта s, чтобы изменить его на «переопределить переменную s».
• Вы помещаете ссылку на 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блок try не будет игнорироваться, если finallyблок определен, только если этот блок finally также включает в себя return.

Это сомнительное дизайнерское решение, которое, вероятно, было ошибкой в ​​ретроспективе (очень похоже на то, что ссылки по умолчанию могут быть обнуляемыми / изменяемыми и, по некоторым данным, проверенными исключениями). Во многих отношениях это поведение в точности соответствует разговорному пониманию того, что finallyозначает - «независимо от того, что происходит заранее в tryблоке, всегда выполняйте этот код». Следовательно, если вы возвращаете true из finallyблока, общий эффект всегда должен бытьreturn s , нет?

В общем, это редко хорошая идиома, и вы должны finallyсвободно использовать блоки для очистки / закрытия ресурсов, но редко, если когда-либо возвращаете значение из них.

Попробуйте это: если вы хотите напечатать значение переопределения s.

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