Dlaczego zmiana zwracanej zmiennej w ostatnim bloku nie zmienia zwracanej wartości?

Mam prostą klasę Java, jak pokazano poniżej:

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

Wynik tego kodu jest następujący:

Entry in finally Block
dev  

Dlaczego snie jest nadpisywany w finallybloku, ale kontroluje wydruk?

W tryfinalizuje bloku z realizacją returnoświadczenia i wartości sw momencie returnoświadczenie wykonuje to wartość zwracana przez metodę. Fakt, że finallyklauzula później zmienia wartość s(po zakończeniu returninstrukcji) nie zmienia (w tym momencie) wartości zwracanej.

Zwróć uwagę, że powyższe dotyczy zmian wartości ssamego siebie w finallybloku, a nie obiektu, do którego się sodnosi. Gdyby sbyło odniesieniem do zmiennego obiektu (a Stringnie jest), a zawartość obiektu została zmieniona w finallybloku, to te zmiany byłyby widoczne w zwracanej wartości.

Szczegółowe zasady działania tego wszystkiego można znaleźć w sekcji 14.20.2 specyfikacji języka Java . Należy zauważyć, że wykonanie returninstrukcji liczy się jako nagłe zakończenie trybloku (obowiązuje sekcja rozpoczynająca się od „ Jeśli wykonanie bloku try nagle kończy się z innego powodu R… ”). Zobacz sekcję 14.17 JLS, aby dowiedzieć się, dlaczego returnoświadczenie jest nagłym zakończeniem bloku.

W celu uzyskania dalszych szczegółów: jeśli zarówno tryblokada, jak i finallyblokada try-finallyoświadczenia returnulegają nagłemu przerwaniu z powodu oświadczeń, wówczas obowiązują następujące zasady z §14.20.2:

Jeśli wykonanie trybloku kończy się nagle z innego powodu R [oprócz rzucenia wyjątku], wtedy finallyblok jest wykonywany, a następnie jest wybór:

• Jeśli finallyblok kończy się normalnie, tryinstrukcja kończy się nagle z powodu R.
• Jeśli finallyblok kończy się nagle z powodu S, to tryinstrukcja kończy się nagle z powodu S (i powód R jest odrzucany).

W rezultacie returninstrukcja w finallybloku określa zwracaną wartość całej try-finallyinstrukcji, a wartość zwracana z trybloku jest odrzucana. Podobnie dzieje się w try-catch-finallyinstrukcji, jeśli tryblok zgłasza wyjątek, zostaje przechwycony przez catchblok i zarówno blok, jak catchi finallyblok mają returninstrukcje.

Ponieważ wartość zwracana jest umieszczana na stosie przed wywołaniem last.

Jeśli zajrzymy do kodu bajtowego, zauważymy, że JDK dokonał znaczącej optymalizacji, a metoda foo () wygląda następująco:

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

I kod bajtowy:

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 zachował ciąg znaków „dev” przed zmianą przed zwróceniem. W rzeczywistości nie ma tu żadnego ostatecznego bloku.

Na uwagę zasługują 2 rzeczy:

• Ciągi znaków są niezmienne. Kiedy ustawiasz s na „przesłonięcie zmiennej s”, ustawiasz s tak, aby odwoływało się do wstawionego ciągu znaków, nie zmieniając wewnętrznego bufora znaków obiektu s na „przesłonięcie zmiennej s”.
• Umieszczasz odniesienie do s na stosie, aby powrócić do kodu wywołującego. Później (gdy ostatni blok zostanie uruchomiony), zmiana odwołania nie powinna robić nic dla wartości zwracanej już na stosie.

Zmieniam trochę twój kod, żeby udowodnić cel Teda.

Jak widać na wyjściu sjest rzeczywiście zmieniony ale po powrocie.

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

Wynik:

Entry in finally Block 
dev 
override variable s

Technicznie rzecz biorąc, returnblok w try nie będzie ignorowany, jeśli finallyblok jest zdefiniowany, tylko jeśli ten ostatni blok zawiera również return.

Jest to wątpliwa decyzja projektowa, która prawdopodobnie była błędem z perspektywy czasu (podobnie jak odniesienia domyślnie dopuszczają wartość null / mutable i, według niektórych, sprawdzane wyjątki). Pod wieloma względami to zachowanie jest dokładnie zgodne z potocznym rozumieniem tego, co finallyoznacza - „bez względu na to, co wydarzy się wcześniej w trybloku, zawsze uruchamiaj ten kod”. Dlatego jeśli zwrócisz prawdę z finallybloku, ogólny efekt zawsze musi być do return s, nie?

Ogólnie rzecz biorąc, rzadko jest to dobry idiom i powinieneś finallyswobodnie używać bloków do czyszczenia / zamykania zasobów, ale rzadko, jeśli w ogóle, zwracaj z nich wartość.

Spróbuj tego: Jeśli chcesz wydrukować wartość przesłonięcia s.

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