Compte tenu de ce code, puis-je être absolument sûr que le finallybloc s'exécute toujours, quel qu'il something()soit?

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

Oui, finallysera appelé après l'exécution des blocs de code tryou catch.

Les seules heures finallyqui ne seront pas appelées sont:

1. Si vous invoquez System.exit()
2. Si vous invoquez Runtime.getRuntime().halt(exitStatus)
3. Si la JVM plante en premier
4. Si la machine virtuelle Java atteint une boucle infinie (ou une autre instruction non interruptible et sans terminaison) dans le bloc tryorcatch
5. Si le système d'exploitation met fin de force au processus JVM; par exemple, kill -9 <pid>sous UNIX
6. Si le système hôte meurt; par exemple, panne de courant, erreur matérielle, panique du système d'exploitation, et cetera
7. Si le finallybloc va être exécuté par un thread démon et que tous les autres threads non démons se terminent avant, finallyest appelé

Exemple de code:

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

Production:

finally trumps return. 
0

De plus, bien que ce soit une mauvaise pratique, s'il y a une instruction return dans le bloc finally, elle l'emportera sur tout autre retour du bloc normal. Autrement dit, le bloc suivant retournerait faux:

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

Même chose avec le lancement d'exceptions du bloc finally.

Voici les mots officiels de la spécification du langage Java.

14.20.2. Exécution de try-finally et try-catch-finally

Une tryinstruction avec un finallybloc est exécutée en exécutant d'abord le trybloc. Ensuite, il y a le choix:

• Si l'exécution du try bloc se termine normalement, [...]
• Si l'exécution du trybloc se termine brutalement à cause throwd'une valeur V , [...]
• Si l'exécution du trybloc se termine brutalement pour toute autre raison R , alors le finallybloc est exécuté. Ensuite, il y a le choix:
  • Si le bloc finalement se termine normalement, alors l' tryinstruction se termine brusquement pour la raison R .
  • Si le finallybloc se termine brusquement pour la raison S , alors l' tryinstruction se termine brusquement pour la raison S ( et la raison R est rejetée ).

La spécification de returnrend cela explicite:

JLS 14.17 La déclaration de retour

ReturnStatement:
     return Expression(opt) ;

Une returndéclaration sans Expression tentatives de transfert de contrôle à l'appelant de la méthode ou du constructeur qui le contient.

Une returndéclaration avec une Expression tentative de transfert du contrôle à l'invocateur de la méthode qui le contient; la valeur de laExpression devient la valeur de l'appel de méthode.

Les descriptions précédentes disent " tente de transférer le contrôle " plutôt que simplement " transfère le contrôle " car s'il y a destryinstructions dans la méthode ou le constructeur dont lestryblocs contiennent l'returninstruction, alors toutes lesfinallyclauses de cestryinstructions seront exécutées, dans l'ordre, du plus interne au plus externe , avant que le contrôle ne soit transféré à l'appelant de la méthode ou du constructeur. L'achèvement brutal d'unefinallyclause peut perturber le transfert de contrôle initié par unereturndéclaration.

En plus des autres réponses, il est important de souligner que «finalement» a le droit de remplacer toute exception / valeur retournée par le bloc try..catch. Par exemple, le code suivant renvoie 12:

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

De même, la méthode suivante ne lève pas d'exception:

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

Alors que la méthode suivante le lance:

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

J'ai essayé l'exemple ci-dessus avec une légère modification-

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

Le code ci-dessus génère:

l'emporte enfin sur le retour.
2

C'est parce que quand return i;est exécuté ia une valeur 2. Après cela, le finallybloc est exécuté où 12 est assigné à ipuis System.outout est exécuté.

Après avoir exécuté le finallybloc, letry bloc renvoie 2, au lieu de renvoyer 12, car cette instruction de retour n'est pas exécutée à nouveau.

Si vous déboguez ce code dans Eclipse, vous aurez l'impression qu'après l'exécution System.outdu finallybloc, l' returninstruction de trybloc est exécutée à nouveau. Mais ce n'est pas le cas. Il renvoie simplement la valeur 2.

Voici une élaboration de la réponse de Kevin . Il est important de savoir que l'expression à renvoyer est évaluée avant finally, même si elle est retournée après.

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

Production:

X
finally trumps return... sort of
0

C'est toute l'idée d'un bloc enfin. Il vous permet de vous assurer que vous effectuez des nettoyages qui pourraient autrement être ignorés car vous revenez, entre autres, bien sûr.

Est finalement appelé indépendamment de ce qui se passe dans le bloc try (à moins que vous n'appeliez System.exit(int)ou que la machine virtuelle Java ne démarre pour une autre raison).

Une façon logique d'y penser est:

1. Le code placé dans un bloc finally doit être exécuté quoi qu'il se passe dans le bloc try
2. Donc, si le code du bloc try tente de renvoyer une valeur ou de lever une exception, l'élément est placé «sur l'étagère» jusqu'à ce que le bloc finally puisse s'exécuter
3. Parce que le code dans le bloc finally a (par définition) une priorité élevée, il peut retourner ou jeter ce qu'il veut. Dans ce cas, tout ce qui reste «sur l'étagère» est jeté.
4. La seule exception à cela est si la machine virtuelle s'arrête complètement pendant le bloc try, par exemple par 'System.exit'

enfin est toujours exécuté sauf en cas de fin anormale du programme (comme appeler System.exit (0) ..). donc, votre sysout sera imprimé

De plus, un retour entraînera la suppression de toute exception. http://jamesjava.blogspot.com/2006/03/dont-return-in-finally-clause.html

Le bloc finally est toujours exécuté sauf en cas de fin anormale du programme, résultant soit d'un crash de la JVM, soit d'un appel à System.exit(0).

En plus de cela, toute valeur renvoyée à l'intérieur du bloc finally remplacera la valeur retournée avant l'exécution du bloc finally, alors faites attention à vérifier tous les points de sortie lorsque vous utilisez try enfin.

Non, pas toujours un cas d'exception est // System.exit (0); avant que le bloc finalement empêche finalement d'être exécuté.

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

Enfin est toujours exécuté, c'est tout le point, juste parce qu'il apparaît dans le code après le retour ne signifie pas que c'est comme ça qu'il est implémenté. Le runtime Java a la responsabilité d'exécuter ce code lors de la sortie du trybloc.

Par exemple, si vous disposez des éléments suivants:

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

Le runtime va générer quelque chose comme ceci:

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

Si une exception non interceptée est levée, le finallybloc s'exécute et l'exception continue de se propager.

En effet, vous avez affecté la valeur de i à 12, mais vous n'avez pas renvoyé la valeur de i à la fonction. Le code correct est le suivant:

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

Parce qu'un bloc finally sera toujours appelé à moins que vous n'appeliez System.exit()(ou que le thread ne plante).

De manière concise, dans la documentation Java officielle (cliquez ici ), il est écrit que -

Si la JVM se ferme pendant l'exécution du code try ou catch, le bloc finally peut ne pas s'exécuter. De même, si le thread exécutant le code try ou catch est interrompu ou tué, le bloc finally peut ne pas s'exécuter même si l'application dans son ensemble continue.

La réponse est simple OUI .

CONTRIBUTION:

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

PRODUCTION:

catch
finally

Oui, il sera appelé. C'est tout l'intérêt d'avoir un mot-clé enfin. Si sauter hors du bloc try / catch pouvait simplement sauter le bloc finalement, c'était la même chose que de mettre System.out.println en dehors du try / catch.

Oui, enfin le bloc est toujours exécuté. La plupart des développeurs utilisent ce bloc pour fermer la connexion à la base de données, l'objet d'ensemble de résultats, l'objet d'instruction et les utilisent également dans l'hibernation java pour annuler la transaction.

PAS TOUJOURS

La spécification du langage Java décrit comment try- catch- finallyet try- catchblocs fonctionnent à 14.20.2
En aucun endroit , il précise que le finallybloc est toujours exécuté. Mais pour tous les cas où la try- catch- finallyet try- des finallyblocs complets , il ne précise que , avant la fin finallydoit être exécuté.

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

Le JLS ne garantit pas que FIN est exécuté après CODE . Le JLS garantit que si CODE et NEXT sont exécutés, FIN sera toujours exécuté après CODE et avant NEXT .

Pourquoi le JLS ne garantit-il pas que le finallybloc est toujours exécuté après le trybloc? Parce que c'est impossible. Il est peu probable mais possible que la JVM soit abandonnée (kill, crash, power off) juste après la fin du trybloc mais avant l'exécution du finallybloc. Il n'y a rien que le JLS puisse faire pour éviter cela.

Ainsi, tout logiciel qui, pour son bon comportement, dépend des finallyblocs toujours exécutés une fois leurs tryblocs terminés est buggé.

returnles instructions dans le trybloc ne sont pas pertinentes pour ce problème. Si l'exécution atteint le code après le try- catch- finallyil est garanti que le finallybloc aura été exécuté avant, avec ou sans returninstructions à l'intérieur du trybloc.

Oui, il sera. Peu importe ce qui se passe dans votre bloc try ou catch, à moins que System.exit () ne soit appelé ou que JVM ne plante. s'il y a une instruction de retour dans le (s) bloc (s), finalement sera exécutée avant cette instruction de retour.

Oui, il sera. Le seul cas où ce ne sera pas le cas, c'est que la JVM se ferme ou se bloque

Ajouter à la réponse de @ vibhash car aucune autre réponse n'explique ce qui se passe dans le cas d'un objet mutable comme celui ci-dessous.

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

Sortira

sbupdated 

J'ai essayé, c'est un filetage simple.

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

Le main Threadsera en waitétat pour toujours, donc finallyne sera jamais appelé ,

donc la sortie de la console ne sera pas print String: après wait()oufinally

En accord avec @Stephen C, l'exemple ci-dessus est l'un des troisièmes cas mentionnés ici :

Ajout d'autres possibilités de boucle infinie dans le code suivant:

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

Cas 2: si la JVM plante en premier

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

Réf: Comment planter une JVM?

Cas 6: Si le finallybloc va être exécuté par le démon Threadet que toutes les autres sorties non démon Threadsavant finallysont appelées.

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

sortie: Ceci n'imprime pas "finalement" ce qui implique que "Enfin bloquer" dans "thread démon" ne s'est pas exécuté

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

Considérez le programme suivant:

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

Depuis Java 1.8.162, le bloc de code ci-dessus donne la sortie suivante:

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

cela signifie que l'utilisation finallypour libérer des objets est une bonne pratique comme le code suivant:

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

C'est en fait vrai dans n'importe quel langage ... enfin s'exécutera toujours avant une instruction return, peu importe où ce retour est dans le corps de la méthode. Si ce n'était pas le cas, le bloc finalement n'aurait pas beaucoup de sens.

En plus du point sur le retour pour remplacer finalement un retour dans le bloc try, il en va de même pour une exception. Un bloc finally qui lève une exception remplacera un retour ou une exception levée depuis le bloc try.

finally va s'exécuter et c'est sûr.

finally ne s'exécutera pas dans les cas ci-dessous:

cas 1 :

Lorsque vous exécutez System.exit().

cas 2:

Lorsque votre JVM / Thread plante.

cas 3:

Lorsque votre exécution est arrêtée entre les deux manuellement.

1. Enfin, Block est toujours exécuté. Sauf si et jusqu'à ce que l' instruction System.exit () existe (première instruction dans le bloc enfin).
2. Si system.exit () est la première instruction, alors finalement le bloc ne sera pas exécuté et le contrôle sortira du bloc finalement. Chaque fois que l'instruction System.exit () pénètre enfin dans le bloc jusqu'à l'exécution définitive de cette instruction et lorsque System.exit () apparaît, la force de contrôle sort complètement du bloc finally.