Враховуючи цей код, чи можу я бути абсолютно впевнений, що finallyблок завжди виконується, незалежно від того, що something()це?

try {  
    something();  
    return success;  
}  
catch (Exception e) {   
    return failure;  
}  
finally {  
    System.out.println("I don't know if this will get printed out");
}

Так, finallyбуде викликано після виконання блоків tryабо catchкоду.

Єдиний раз, finallyколи не буде викликано:

1. Якщо ви посилаєтесь System.exit()
2. Якщо ви посилаєтесь Runtime.getRuntime().halt(exitStatus)
3. Якщо JVM виходить з ладу першим
4. Якщо JVM досягає нескінченного циклу (або якого-небудь іншого непереривного заяви, що не припиняється) в блоці tryабоcatch
5. Якщо ОС насильно припиняє процес JVM; наприклад, kill -9 <pid>на UNIX
6. Якщо хост-система гине; наприклад, відключення електроживлення, апаратні помилки, паніка ОС та ін
7. Якщо finallyкадр буде виконуватися з допомогою демона нитку і все інші не демон нитками виходу перед тим finally, називається

Приклад коду:

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

Вихід:

finally trumps return. 
0

Крім того, хоча це є поганою практикою, якщо в остаточному блоці є твердження про повернення, воно викличе будь-яке інше повернення із звичайного блоку. Тобто наступний блок поверне помилкове:

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

Те саме, що викидати винятки з остаточно блоку.

Ось офіційні слова із специфікації мови Java.

14.20.2. Виконання спробу-нарешті та спробу-лов-нарешті

tryЗаява з finallyблоком виконується першим виконанням tryблоку. Тоді є вибір:

• Якщо виконання tryблоку завершується нормально, [...]
• Якщо виконання tryблоку різко закінчується через throwзначення V , [...]
• Якщо виконання tryблоку різко завершується з будь-якої іншої причини R , finallyблок виконується. Тоді є вибір:
  • Якщо , нарешті , блок завершується нормально, то tryоператор завершується передчасно через R .
  • Якщо finallyблок завершується різко через причину S , тоді tryоператор різко завершується з причини S ( а причина R відкидається ).

Специфікація returnфактично робить це явним:

JLS 14.17 Заява про повернення

ReturnStatement:
     return Expression(opt) ;

returnЗаява без будь - яких Expression спроб передати управління, що викликав методу або конструктора , який його містить.

returnЗаява з Expression спробами передати управління, що викликав метод , який його містить; значення параметра Expressionстає значенням виклику методу.

Попередні описи говорять про " спроби передачі контролю ", а не просто " передачу контролю ", тому що якщо tryв методі чи конструкторі є які-небудь оператори, tryблоки яких містять returnвисловлювання, то будь-які finallyпропозиції цих tryоператорів будуть виконані в порядку, що є найглибшим до зовнішнього , перш ніж керування буде передано користувачеві методу чи конструктора. Швидке виконання finallyпункту може порушити передачу контролю, ініційовану returnзаявою.

На додаток до інших відповідей важливо зазначити, що "нарешті" має право замінити будь-яке виключення / повернене значення блоком try..catch. Наприклад, наступний код повертає 12:

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

Аналогічно, наступний метод не є винятком:

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

У той час як наступний метод робить це:

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

Я спробував наведений приклад з незначною модифікацією-

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

Наведені вище коди:

нарешті козирі повертаються.
2

Це тому, що коли return i;виконується, iмає значення 2. Після цього finallyблок виконується там, де 12 присвоюється, iа потім System.outвиконується.

Після виконання finallyблоку tryблок повертає 2, а не повертає 12, оскільки ця операція повернення не виконується знову.

Якщо ви будете налагоджувати цей код в Eclipse , то ви отримаєте відчуття , що після виконання System.outз finallyблоку на returnзаяві tryблоку виконуються знову. Але це не так. Він просто повертає значення 2.

Ось розробка відповіді Кевіна . Важливо знати, що вираження, яке потрібно повернути, оцінюється раніше finally, навіть якщо воно повертається після.

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

Вихід:

X
finally trumps return... sort of
0

Ось і вся ідея остаточного блоку. Це дозволяє вам переконатися, що ви робите прибирання, які в іншому випадку можуть бути пропущені, тому що, крім іншого, ви повернетесь, звичайно.

Нарешті телефонує незалежно від того, що відбувається у блоці спробу ( якщо ви не дзвоните System.exit(int)або Java Virtual Machine не починається з якоїсь іншої причини).

Логічний спосіб подумати над цим:

1. Код, розміщений в остаточному блоці, повинен виконуватися все, що відбувається в блоці спробу
2. Отже, якщо код у блоці спробу намагається повернути значення або викинути виняток, елемент розміщується "на полиці", поки нарешті блок не може виконати
3. Оскільки код в остаточному блоці має (за визначенням) високий пріоритет, він може повернути або кинути все, що йому заманеться. У такому випадку все, що залишилося "на полиці", викидається.
4. Єдиним винятком з цього є те, якщо VM повністю вимикається під час пробного блоку, наприклад, "System.exit"

нарешті завжди виконується, якщо немає аномального завершення програми (наприклад, виклик System.exit (0) ..). Таким чином, ваша система буде надрукована

Також повернення нарешті викине будь-який виняток. http://jamesjava.blogspot.com/2006/03/dont-return-in-finally-clause.html

Остаточний блок завжди виконується, якщо немає аномального завершення програми, або в результаті аварії JVM або від виклику до System.exit(0).

Крім того, будь-яке значення, повернене зсередини блоку нарешті, замінить значення, повернене перед виконанням остаточного блоку, тому будьте уважні до перевірки всіх точок виходу при використанні спроби остаточно.

Ні, не завжди один виняток є // System.exit (0); перед тим, як нарешті блок запобігає остаточно виконувати

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

Нарешті, завжди виконується, у цьому вся суть, лише тому, що він з'являється в коді після повернення, не означає, що саме так він реалізований. Виконання Java несе відповідальність за виконання цього коду під час виходу з tryблоку.

Наприклад, якщо у вас є наступне:

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

Час виконання буде генерувати щось подібне:

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

Якщо буде викинуто невиконане виключення, finallyблок запуститься, і виняток продовжить розповсюдження.

Це тому, що ви присвоїли значення i як 12, але не повернули функції i функції. Правильний код такий:

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

Тому що, нарешті, блок завжди буде викликатися, якщо ви не зателефонуєте System.exit()(або потік обривається).

Точно в офіційній Документації Java (Клацніть тут ) написано, що -

Якщо JVM закінчується, поки виконується код спробу лову, блок остаточно може не виконуватись. Так само, якщо потік, який виконує код спробу вилову, перерваний або знищений, остаточний блок може не виконатись, хоча програма в цілому продовжується.

Відповідь проста ТАК .

ВХОД:

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

ВИХІД:

catch
finally

Так, це подзвонить. В цьому і полягає вся суть останнього ключового слова. Якщо вистрибнути з блоку try / catch можна просто пропустити остаточний блок, це було те саме, що поставити System.out.println за межі try / catch.

Так, нарешті блок завжди виконується. Більшість розробників використовують цей блок, закриваючи підключення до бази даних, об'єкт набору результатів, об’єкт заяви, а також використовує в сплячому режимі Java для відкату транзакції.

НЕ ЗАВЖДИ

Специфікація мови Java описує, як try- catch- finallyі try- catchблоки працюють о 14.20.2. Ні
в якому місці вона не вказує, що finallyблок завжди виконується. Але для всіх випадків, коли блоки try- catch- finallyі try- finallyзавершені, це вказує, що перед завершенням finallyпотрібно виконати.

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 не гарантує, що FIN виконується після КОДУ . JLS гарантує, що якщо CODE і NEXT виконуються, то FIN завжди буде виконуватися після CODE та до NEXT .

Чому JLS не гарантує, що finallyблок завжди виконується після tryблоку? Бо це неможливо. Навряд чи можливо, що JVM буде перервано (вбити, вийти з ладу, вимкнути живлення) відразу після заповнення tryблоку, але до його виконання finally. JLS нічого не може зробити, щоб цього уникнути.

Таким чином, будь-яке програмне забезпечення, яке для їх належної поведінки залежить від finallyблоків, які завжди виконуються після tryзавершення їх блоку, помиляється.

returnінструкції в tryблоці не стосуються цього питання. Якщо виконання досягне коду після try- catch- finallyгарантується, що finallyблок буде виконаний раніше, з returnінструкціями всередині tryблоку або без них .

Так, буде. Незалежно від того, що відбувається у вашому блоці спробу вловлювання, якщо інше не викликано System.exit () або JVM. якщо в блоці (блоках) є який-небудь оператор повернення, нарешті він буде виконаний перед цим оператором повернення.

Так, буде. Єдиний випадок, коли це не буде, це вихід або збій JVM

Додавши до @ vibhash відповідь, як жодна інша відповідь не пояснює, що відбувається у випадку з об'єктом, що змінюється, на зразок наведеного нижче.

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

Вийде

sbupdated 

Я спробував це, це одна різьба.

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

main ThreadБуде на waitстані назавжди, отже , finallyніколи не буде називатися ,

тому консольний вихід не буде print String: після wait()абоfinally

Погоджено з @Stephen C, наведений вище приклад є одним з 3 - й випадок згадки тут :

Додавання ще декількох таких нескінченних можливостей циклу у наступному коді:

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

Випадок 2: Якщо СП виходить з ладу першим

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: Як ви розбиваєте JVM?

Випадок 6: Якщо finallyблок буде виконаний демоном, Threadа всі інші недемонові Threadsвиклики раніше 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("-------------------------------------------------");
}

вихід: Це не друкує "нарешті", що означає, що "Нарешті блок" у "демоновій нитці" не виконується

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

Розглянемо наступну програму:

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

Станом на Java 1.8.162, наведений вище код коду дає такий вихід:

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

це означає, що використання finallyдля звільнення об'єктів є хорошою практикою, як наступний код:

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.
    }
}

Це насправді вірно на будь-якій мові ... нарешті завжди виконується перед оператором return, незалежно від того, де це повернення знаходиться в тілі методу. Якби це не так, то нарешті блок не мав би великого значення.

На додаток до питання про повернення нарешті заміни повернення у блоці спробу, те саме стосується винятку. Нарешті, блок, який видає виняток, замінить повернення або виняток, викинутий з блоку спробу.

finally виконати, і це точно.

finally не буде виконано у наведених нижче випадках:

випадок 1:

Коли ви виконуєте System.exit().

випадок 2:

Коли ваш JVM / Thread виходить з ладу.

випадок 3:

Коли ваше виконання зупиняється між ними вручну.

1. Нарешті, Блок завжди виконується. Якщо тільки і поки System.exit () існує оператора (перший вислів, нарешті, блок).
2. Якщо system.exit () є першим оператором, тоді нарешті блок не буде виконаний, а контроль вийде з остаточного блоку. Кожен раз, коли оператор System.exit () потрапляє в остаточний блок, поки цей оператор остаточно блокується, і коли з'являється System.exit (), сила управління повністю виходить з остаточного блоку.