Przykładowy kod:

public static void main(String[] args) {
    System.out.println(Test.test());
}

public static int test() {
    try {
        return 0;
    }
    finally {
        System.out.println("finally trumps return.");
    }
}

Wyjście:

finally trumps return. 
0

Ponadto, chociaż jest to zła praktyka, jeśli w bloku finally znajduje się polecenie return, przebije ono każdy inny powrót ze zwykłego bloku. Oznacza to, że następujący blok zwróci false:

try { return true; } finally { return false; }

To samo z wyrzucaniem WYJĄTKÓW z bloku finally.

Oto oficjalne słowa ze specyfikacji języka Java.

14.20.2. Wykonanie try-finally I try-catch-finally

Instrukcja try z blokiem finally jest wykonywana przez pierwsze wykonanie bloku try. Następnie jest wybór:

• jeśli wykonanie try bloku zakończy się normalnie, [...]
• jeśli wykonanie bloku try zakończy się nagle z powodu throw o wartości V , [...]
• jeśli wykonanie try bloku zakończy się nagle z jakiegokolwiek innego powodu R , to finally Blok jest wykonywany. Wtedy jest wybór:
  • jeśli blok finalny kończy się normalnie, to polecenie try kończy się nagle z powodu R .
  • jeśli finallyblok kończy się nagle z powodu S , to try Instrukcja kończy się nagle z powodu S (i rozum R jest odrzucone ).

Specyfikacja dla return faktycznie czyni to wyraźnie:

JLS 14.17 the return Statement

ReturnStatement:
     return Expression(opt) ;

A return Oświadczenie o nie Expression próbuje przenieść kontrolę do wywołującego metodę lub konstruktor, który ją zawiera.

A return oświadczenie z Expression próbuje przenieść kontrolę do wywołującego metodę, która ją zawiera; wartość Expression staje się wartością wywołania metody.

Poprzednie opisy mówią "próby przeniesienia kontroli "zamiast tylko" przeniesienia kontroli ", ponieważ jeśli w metodzie lub konstruktorze znajdują się jakieś polecenia try, których bloki try zawierają instrukcję return, to Wszelkie finally klauzule tych instrukcji try będą wykonywane w kolejności od najbardziej wewnętrznej do zewnętrznej, zanim kontrola zostanie przekazana do wywołującego metodę lub konstruktora. konstruktor. Nagłe zakończenie finally klauzuli może zakłócić transfer kontroli zainicjowany przez return oświadczenie.

Oprócz innych odpowiedzi, ważne jest, aby zaznaczyć, że 'finally' ma prawo nadpisać dowolny wyjątek / zwróconą wartość przez próbę../ align = "left" / Na przykład następujący kod zwraca 12:

public static int getMonthsInYear() {
    try {
        return 10;
    }
    finally {
        return 12;
    }
}

Podobnie, następująca metoda nie wyrzuca wyjątku:

public static int getMonthsInYear() {
    try {
        throw new RuntimeException();
    }
    finally {
        return 12;
    }
}

Podczas gdy następująca metoda rzuca go:

public static int getMonthsInYear() {
    try {
        return 12;          
    }
    finally {
        throw new RuntimeException();
    }
}

Oto opracowanie odpowiedzi Kevina . Ważne jest, aby wiedzieć, że zwracane wyrażenie jest oceniane przed finally, nawet jeśli jest zwracane po.

public static void main(String[] args) {
    System.out.println(Test.test());
}

public static int printX() {
    System.out.println("X");
    return 0;
}

public static int test() {
    try {
        return printX();
    }
    finally {
        System.out.println("finally trumps return... sort of");
    }
}

Wyjście:

X
finally trumps return... sort of
0

Wypróbowałem powyższy przykład z lekką modyfikacją -

public static void main(final String[] args) {
    System.out.println(test());
}

public static int test() {
    int i = 0;
    try {
        i = 2;
        return i;
    } finally {
        i = 12;
        System.out.println("finally trumps return.");
    }
}

Powyższy kod wyprowadza:

W końcu przebija powrót.
2

Dzieje się tak dlatego, że gdy return i; jest wykonywane i ma wartość 2. Następnie wykonywany jest blok finally, gdzie 12 jest przypisane do i, a następnie wykonywane jest wyjście System.out.

Po wykonaniu finally block try block zwraca 2, zamiast zwracać 12, ponieważ ta instrukcja return nie jest wykonywana jeszcze raz.

Jeśli debugujesz ten kod w Eclipse to masz wrażenie, że po wykonaniu System.out z finally block return Instrukcja try block jest wykonywana ponownie. Ale tak nie jest. Po prostu zwraca wartość 2.

To jest cała idea ostatecznego bloku. Pozwala to na upewnienie się, że czyścisz, które w przeciwnym razie mogą zostać pominięte, ponieważ zwracasz, między innymi, oczywiście.

W końcu zostanie wywołana niezależnie od tego, co się stanie w bloku try ( chyba że zadzwonisz System.exit(int) lub wirtualna maszyna Javy zostanie wyrzucona z innego powodu).

Logicznym sposobem myślenia o tym jest:

1. kod umieszczony w bloku finally musi zostać wykonany niezależnie od tego, co nastąpi w bloku try
2. więc jeśli kod w bloku try spróbuje zwrócić wartość lub wyrzucić wyjątek, element jest umieszczany 'na półce', aż ostatecznie blok będzie mógł wykonać
3. ponieważ kod w bloku finally ma (z definicji) wysoki priorytet, może zwracać lub rzucać co tylko zechce. W takim przypadku wszystko, co zostało "na półce" jest odrzucony.
4. jedynym wyjątkiem jest całkowite wyłączenie maszyny wirtualnej podczas bloku try, np. przez ' System.exit"

Finally jest zawsze wykonywane, o ile nie ma nieprawidłowego zakończenia programu(jak wywołanie systemu.exit (0).). tak więc twój sysout zostanie wydrukowany

Również return in w końcu wyrzuci każdy wyjątek. http://jamesjava.blogspot.com/2006/03/dont-return-in-finally-clause.html

Nie, Nie zawsze jednym wyjątkiem jest// System.exit(0); przed blokiem finally uniemożliwia wykonanie finally.

  class A {
    public static void main(String args[]){
        DataInputStream cin = new DataInputStream(System.in);
        try{
            int i=Integer.parseInt(cin.readLine());
        }catch(ArithmeticException e){
        }catch(Exception e){
           System.exit(0);//Program terminates before executing finally block
        }finally{
            System.out.println("Won't be executed");
            System.out.println("No error");
        }
    }
}

Blok finally jest zawsze wykonywany, chyba że doszło do nieprawidłowego zakończenia programu, wynikającego z awarii JVM lub wywołania System.exit(0).

Ponadto, każda wartość zwracana z bloku finally nadpisze wartość zwróconą przed wykonaniem bloku finally, więc należy uważać na sprawdzanie wszystkich punktów wyjścia podczas używania try finally.

Finally is always run that ' s the whole point, to że pojawia się w kodzie po powrocie nie oznacza, że tak to jest zaimplementowane. Środowisko uruchomieniowe Java jest odpowiedzialne za uruchomienie tego kodu po wyjściu z bloku try.

Na przykład, jeśli masz:

int foo() { 
    try {
        return 42;
    }
    finally {
        System.out.println("done");
    }
}

Runtime wygeneruje coś takiego:

int foo() {
    int ret = 42;
    System.out.println("done");
    return 42;
}

Jeśli zostanie wyrzucony nieobciążony wyjątek, blok finally zostanie uruchomiony i wyjątek będzie nadal się rozmnażał.

Dzieje się tak dlatego, że przypisałeś wartość i jako 12, ale nie zwróciłeś wartości i do funkcji. Prawidłowy kod jest następujący:

public static int test() {
    int i = 0;
    try {
        return i;
    } finally {
        i = 12;
        System.out.println("finally trumps return.");
        return i;
    }
}

Odpowiedź jest prosta Tak .

INPUT:

try{
    int divideByZeroException = 5 / 0;
} catch (Exception e){
    System.out.println("catch");
    return;    // also tried with break; in switch-case, got same output
} finally {
    System.out.println("finally");
}

Wyjście:

catch
finally

Tak, zostanie wezwany. O to właśnie chodzi, żeby mieć wreszcie słowo kluczowe. Jeśli wyskakując z bloku try/catch można po prostu pominąć blok ostatecznie to było to samo, co wprowadzenie systemu.Wynocha.println poza try / catch.

Ponieważ blok finally będzie zawsze wywoływany, chyba że wywołasz System.exit() (lub wątek się zawiesi).

Zwięźle, w oficjalnej dokumentacji Javy (Kliknij tutaj) jest napisane, że -

Jeśli JVM zakończy działanie podczas wykonywania kodu try lub catch, to ostatni blok może nie zostać wykonany. Podobnie, jeśli wątek wykonujący kod try or catch zostaje przerwany lub zabity, ostatecznie blok może nie wykonaj, nawet jeśli aplikacja jako całość nadal trwa.

Tak, będzie. Bez względu na to, co dzieje się w bloku try lub catch, chyba że system inaczej.wywołane exit() lub JVM się rozbił. jeśli w bloku(blokach) znajduje się jakakolwiek Instrukcja return,finally zostanie wykonane przed tą instrukcją return.

Tak, w końcu blok jest zawsze wykonywany. Większość programistów blokuje zamknięcie połączenia z bazą danych, obiektu resultset, obiektu instrukcji, a także wykorzystuje do hibernate Javy, aby cofnąć transakcję.

NIE ZAWSZE

Specyfikacja języka Java opisuje jak try-catch-finally oraz try-catch bloki pracują w 14.20.2
W żadnym miejscu nie określa, że blok finally jest zawsze wykonywany. Ale dla wszystkich przypadków, w których try-catch-finally oraz try-finally blocks complete określa, że przed zakończeniem finally musi zostać wykonane.

try {
  CODE inside the try block
}
finally {
  FIN code inside finally block
}
NEXT code executed after the try-finally block (may be in a different method).

JLS nie gwarantuje, że FIN zostanie wykonany po kodzie . JLS gwarantuje, że jeśli CODE I NEXT są wykonywane wtedy FIN będzie zawsze wykonywany po CODE i przed NEXT.

Dlaczego JLS nie gwarantuje, że finally blok jest zawsze wykonywany po try bloku? Ponieważ to niemożliwe. jest mało prawdopodobne, ale możliwe, że JVM zostanie przerwany (kill, crash, power off) tuż po zakończeniu try bloku, ale przed wykonaniem finally bloku. JLS nie może nic zrobić, aby uniknąć to.

Tak więc każde oprogramowanie, które ze względu na swoje właściwe zachowanie zależy od finally bloków zawsze wykonywanych po ich try blokach skończonych, jest podsłuchiwane.

return instrukcje w bloku try nie mają znaczenia dla tego problemu. Jeśli wykonanie osiągnie kod po try-catch-finally jest gwarantowane, że blok finally zostanie wykonany wcześniej, z instrukcjami return wewnątrz bloku try lub bez nich.

Tak będzie. Tylko w przypadku, gdy nie będzie to wyjście lub awaria JVM

Dodanie do @ vibhash ' s answer jak żadna inna odpowiedź nie wyjaśnia, co się dzieje w przypadku mutowalnego obiektu, takiego jak ten poniżej.

public static void main(String[] args) {
    System.out.println(test().toString());
}

public static StringBuffer test() {
    StringBuffer s = new StringBuffer();
    try {
        s.append("sb");
        return s;
    } finally {
        s.append("updated ");
    }
}

Wyświetli

sbupdated 

Próbowałem tego, Jest to pojedynczy gwintowany.

public static void main(String args[]) throws Exception {
    Object obj = new Object();
    try {
        synchronized (obj) {
            obj.wait();
            System.out.println("after wait()");
        }
    } catch (Exception ignored) {
    } finally {
        System.out.println("finally");
    }
}

The main Thread będzie na wait Stan na zawsze, stąd finally nigdy nie będzie nazywany ,

Więc wyjście konsoli nie będzieprint String: po wait() lub finally

Zgadzam się z @ Stephen C, powyższy przykład jest jednym z 3. przypadków wzmianki tutaj :

Dodanie kilku takich nieskończonych możliwości pętli w następującym kodzie:

// import java.util.concurrent.Semaphore;

public static void main(String[] args) {
    try {
        // Thread.sleep(Long.MAX_VALUE);
        // Thread.currentThread().join();
        // new Semaphore(0).acquire();
        // while (true){}
        System.out.println("after sleep join semaphore exit infinite while loop");
    } catch (Exception ignored) {
    } finally {
        System.out.println("finally");
    }
}

Przypadek 2: jeśli JVM ulegnie awarii jako pierwszy

import sun.misc.Unsafe;
import java.lang.reflect.Field;

public static void main(String args[]) {
    try {
        unsafeMethod();
        //Runtime.getRuntime().halt(123);
        System.out.println("After Jvm Crash!");
    } catch (Exception e) {
    } finally {
        System.out.println("finally");
    }
}

private static void unsafeMethod() throws NoSuchFieldException, IllegalAccessException {
    Field f = Unsafe.class.getDeclaredField("theUnsafe");
    f.setAccessible(true);
    Unsafe unsafe = (Unsafe) f.get(null);
    unsafe.putAddress(0, 0);
}

Ref: jak rozbić JVM?

Przypadek 6: Jeśli finally blok zostanie uruchomiony przez demona Thread i wszystkie inne nie-demony Threads zostaną wywołane przed wywołaniem finally.

public static void main(String args[]) {
    Runnable runnable = new Runnable() {
        @Override
        public void run() {
            try {
                printThreads("Daemon Thread printing");
                // just to ensure this thread will live longer than main thread
                Thread.sleep(10000);
            } catch (Exception e) {
            } finally {
                System.out.println("finally");
            }
        }
    };
    Thread daemonThread = new Thread(runnable);
    daemonThread.setDaemon(Boolean.TRUE);
    daemonThread.setName("My Daemon Thread");
    daemonThread.start();
    printThreads("main Thread Printing");
}

private static synchronized void printThreads(String str) {
    System.out.println(str);
    int threadCount = 0;
    Set<Thread> threadSet = Thread.getAllStackTraces().keySet();
    for (Thread t : threadSet) {
        if (t.getThreadGroup() == Thread.currentThread().getThreadGroup()) {
            System.out.println("Thread :" + t + ":" + "state:" + t.getState());
            ++threadCount;
        }
    }
    System.out.println("Thread count started by Main thread:" + threadCount);
    System.out.println("-------------------------------------------------");
}

Wyjście: nie wyświetla "finally "co oznacza" Finally block " w "DAEMON thread" nie został wykonany

main Thread Printing  
Thread :Thread[My Daemon Thread,5,main]:state:BLOCKED  
Thread :Thread[main,5,main]:state:RUNNABLE  
Thread :Thread[Monitor Ctrl-Break,5,main]:state:RUNNABLE   
Thread count started by Main thread:3  
-------------------------------------------------  
Daemon Thread printing  
Thread :Thread[My Daemon Thread,5,main]:state:RUNNABLE  
Thread :Thread[Monitor Ctrl-Break,5,main]:state:RUNNABLE  
Thread count started by Main thread:2  
-------------------------------------------------  

Process finished with exit code 0

Rozważ następujący program:

public class SomeTest {

    private static StringBuilder sb = new StringBuilder();

    public static void main(String args[]) {

        System.out.println(someString());
        System.out.println("---AGAIN---");
        System.out.println(someString());
        System.out.println("---PRINT THE RESULT---");
        System.out.println(sb.toString());
    }

    private static String someString() {

        try {
            sb.append("-abc-");
            return sb.toString();

        } finally {
            sb.append("xyz");
        }
    }
}

Od wersji Java 1.8.162 powyższy blok kodu daje następujące wyjście:

-abc-
---AGAIN---
-abc-xyz-abc-
---PRINT THE RESULT---
-abc-xyz-abc-xyz

Oznacza to, że używanie finally do zwalniania obiektów jest dobrą praktyką, jak poniższy kod:

private static String someString() {

    StringBuilder sb = new StringBuilder();

    try {
        sb.append("abc");
        return sb.toString();

    } finally {
        sb = null; // Just an example, but you can close streams or DB connections this way.
    }
}

To prawda w każdym języku...finally będzie zawsze wykonywane przed instrukcją return, bez względu na to, gdzie ten zwrot znajduje się w ciele metody. Gdyby tak nie było, ostatni blok nie miałby większego znaczenia.

Oprócz punktu o powrocie w końcu zastąpienie zwrotu w bloku try, to samo dotyczy wyjątku. Blok wreszcie, który wyrzuca wyjątek, zastąpi zwrot lub wyjątek wyrzucony z bloku try.

finally wykonam i to na pewno.

finally nie będzie wykonywana w poniższych przypadkach:

Przypadek 1:

Kiedy wykonujesz System.exit().

Przypadek 2:

Kiedy twój JVM / wątek ulega awarii.

Przypadek 3:

Gdy wykonanie zostanie przerwane ręcznie.

finally jest zawsze wykonywane i przed zwróceniem wartości x (obliczonej).

System.out.println(foo());

....

int foo(){
    int x = 2;
    try{
        return x++;
    } finally{
        System.out.println(x);
    }
}

Wyjście:

3
2