Teniendo en cuenta este código, ¿puedo estar absolutamente seguro de que el finallybloque siempre se ejecuta, sin importar lo que something()sea?

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

Sí, finallyse llamará después de la ejecución de los bloques de código tryo catch.

Los únicos momentos finallyque no se llamarán son:

1. Si invocas System.exit()
2. Si invocas Runtime.getRuntime().halt(exitStatus)
3. Si la JVM se bloquea primero
4. Si la JVM alcanza un bucle infinito (o alguna otra instrucción no interrumpible, sin terminación) en el bloque tryocatch
5. Si el sistema operativo termina por la fuerza el proceso JVM; por ejemplo, kill -9 <pid>en UNIX
6. Si el sistema host muere; por ejemplo, falla de energía, error de hardware, pánico del sistema operativo, etc.
7. Si el finallybloque va a ser ejecutado por un subproceso de demonio y todos los demás subprocesos que no son de demonio salen antes, finallyse llama

Código de ejemplo:

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

Salida:

finally trumps return. 
0

Además, aunque es una mala práctica, si hay una declaración de devolución dentro del bloque finalmente, prevalecerá sobre cualquier otra devolución del bloque regular. Es decir, el siguiente bloque devolvería falso:

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

Lo mismo con lanzar excepciones desde el último bloque.

Aquí están las palabras oficiales de la Especificación del lenguaje Java.

14.20.2. Ejecución de try-finally y try-catch-finally

Una trydeclaración con un finallybloque se ejecuta ejecutando primero el trybloque. Entonces hay una opción:

• Si la ejecución de la try bloque se completa normalmente, [...]
• Si la ejecución del trybloque se completa abruptamente debido a throwun valor V , [...]
• Si la ejecución del trybloque se completa abruptamente por cualquier otra razón R , entonces el finallybloque se ejecuta. Entonces hay una opción:
  • Si el bloque finalmente se completa normalmente, entonces la trydeclaración se completa abruptamente por la razón R .
  • Si el finallybloque se completa abruptamente por la razón S , entonces la trydeclaración se completa abruptamente por la razón S ( y la razón R se descarta ).

La especificación para returnrealmente hace esto explícito:

JLS 14.17 La declaración de devolución

ReturnStatement:
     return Expression(opt) ;

Una returndeclaración sin Expression intentos de transferir el control al invocador del método o constructor que lo contiene.

Una returndeclaración con un Expression intento de transferir el control al invocador del método que lo contiene; el valor de laExpression convierte en el valor de la invocación del método.

Las descripciones anteriores dicen " intentos de transferir el control " en lugar de simplemente " transferir el control " porque si hay alguna trydeclaración dentro del método o constructor cuyos trybloques contengan la returndeclaración, entonces cualquier finallycláusula de esas trydeclaraciones se ejecutará, en orden, de lo más interno a lo más externo. , antes de transferir el control al invocador del método o constructor. La finalización abrupta de una finallycláusula puede interrumpir la transferencia de control iniciada por una returndeclaración.

Además de las otras respuestas, es importante señalar que 'finalmente' tiene el derecho de anular cualquier excepción / valor devuelto por el bloque try..catch. Por ejemplo, el siguiente código devuelve 12:

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

Del mismo modo, el siguiente método no arroja una excepción:

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

Si bien el siguiente método lo arroja:

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

Intenté el ejemplo anterior con una ligera modificación.

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

Las salidas del código anterior:

finalmente triunfa el regreso.
2

Esto se debe a que cuando return i;se ejecuta itiene un valor 2. Después de esto, el finallybloque se ejecuta donde se asigna 12 iy luego System.outse ejecuta out.

Después de ejecutar el finallybloque, eltry bloque devuelve 2, en lugar de devolver 12, porque esta declaración de retorno no se ejecuta nuevamente.

Si va a depurar el código en Eclipse entonces obtendrá una sensación de que después de la ejecución System.outdel finallybloque de la returndeclaración del trybloque se ejecuta de nuevo. Pero este no es el caso. Simplemente devuelve el valor 2.

Aquí hay una elaboración de la respuesta de Kevin . Es importante saber que la expresión a devolver se evalúa antes finally, incluso si se devuelve despué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");
    }
}

Salida:

X
finally trumps return... sort of
0

Esa es la idea de un bloque finalmente. Te permite asegurarte de hacer limpiezas que de otro modo podrían saltarse porque regresas, entre otras cosas, por supuesto.

Finalmente se llama independientemente de lo que ocurra en el bloque de prueba (a menos que llame System.exit(int)o la máquina virtual Java se apague por alguna otra razón).

Una forma lógica de pensar en esto es:

1. El código colocado en un bloque finalmente debe ejecutarse lo que ocurra dentro del bloque try
2. Entonces, si el código en el bloque try intenta devolver un valor o lanzar una excepción, el artículo se coloca 'en el estante' hasta que el bloque finalmente pueda ejecutarse
3. Debido a que el código en el bloque finalmente tiene (por definición) una alta prioridad, puede devolver o arrojar lo que quiera. En cuyo caso, todo lo que quede 'en el estante' se descarta.
4. La única excepción a esto es si la VM se apaga completamente durante el bloque de prueba, por ejemplo, mediante 'System.exit'

finalmente siempre se ejecuta a menos que haya una terminación anormal del programa (como llamar a System.exit (0) ..). entonces, tu sysout se imprimirá

También un retorno finalmente rechazará cualquier excepción. http://jamesjava.blogspot.com/2006/03/dont-return-in-finally-clause.html

El último bloque siempre se ejecuta a menos que haya una terminación anormal del programa, ya sea como resultado de un bloqueo de JVM o de una llamada a System.exit(0).

Además de eso, cualquier valor devuelto desde dentro del último bloque anulará el valor devuelto antes de la ejecución del último bloque, por lo tanto, tenga cuidado de verificar todos los puntos de salida cuando use try finally.

No, no siempre un caso de excepción es // System.exit (0); antes de que finalmente el bloque impida finalmente ser ejecutado.

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

Finalmente, siempre se ejecuta ese es el punto, solo porque aparece en el código después de la devolución no significa que así es como se implementa. El tiempo de ejecución de Java tiene la responsabilidad de ejecutar este código al salir deltry bloque.

Por ejemplo, si tiene lo siguiente:

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

El tiempo de ejecución generará algo como esto:

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

Si se produce una excepción no detectada, el finallybloque se ejecutará y la excepción continuará propagándose.

Esto se debe a que asignó el valor de i como 12, pero no devolvió el valor de i a la función. El código correcto es el siguiente:

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

Porque un bloque finalmente siempre se llamará a menos que llame System.exit()(o el subproceso se bloquea).

De manera concisa, en la documentación oficial de Java (haga clic aquí ), está escrito que:

Si la JVM sale mientras se está ejecutando el código try o catch, entonces el bloque finalmente puede no ejecutarse. Del mismo modo, si el subproceso que ejecuta el código de prueba o captura se interrumpe o finaliza, el bloque finalmente puede no ejecutarse aunque la aplicación en su conjunto continúe.

La respuesta es simple SÍ .

ENTRADA:

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

SALIDA:

catch
finally

Sí, lo llamarán. Ese es el punto de tener finalmente una palabra clave. Si saltar fuera del bloque try / catch podría saltarse el bloque finalmente, era lo mismo que colocar System.out.println fuera del try / catch.

Sí, finalmente el bloque siempre se ejecuta. La mayoría de los desarrolladores usan este bloqueo al cerrar la conexión de la base de datos, el objeto del conjunto de resultados, el objeto de la declaración y también los utiliza en la hibernación de Java para revertir la transacción.

NO SIEMPRE

La especificación del lenguaje Java se describe cómo try- catch- finallyy try- catchbloques trabajan en 14.20.2
En ningún lugar se especifica que el finallybloque se ejecuta siempre. Pero en todos los casos en los que el try- catch- finallyy try- finallybloques completos se especifica que antes de la terminación finallydebe ser ejecutado.

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

El JLS no garantiza que FIN se ejecute después de CODE . El JLS garantiza que si se ejecutan CODE y NEXT , FIN siempre se ejecutará después de CODE y antes de NEXT .

¿Por qué JLS no garantiza que el finallybloque siempre se ejecute después del trybloque? Porque es imposible Es poco probable pero posible que la JVM sea abortada (matar, estrellarse, apagarse) justo después de completar el trybloque pero antes de la ejecución del finallybloque. JLS no puede hacer nada para evitar esto.

Por lo tanto, cualquier software que, para su correcto comportamiento, dependa de que los finallybloques se ejecuten siempre después de que tryse completen sus bloques.

returnlas instrucciones en el trybloque son irrelevantes para este problema. Si la ejecución alcanza el código después de try- catch, finallyse garantiza que el finallybloque se habrá ejecutado antes, con o sin returninstrucciones dentro del trybloque.

Sí lo hará No importa lo que ocurra en el bloque try o catch a menos que se llame System.exit () o JVM se bloquee. Si hay alguna declaración de retorno en el (los) bloque (s), finalmente se ejecutará antes de esa declaración de retorno.

Sí lo hará. El único caso que no será es que JVM salga o se bloquee

Agregar a la respuesta de @ vibhash como ninguna otra respuesta explica lo que sucede en el caso de un objeto mutable como el siguiente.

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

Saldrá

sbupdated 

Intenté esto, es de un solo hilo.

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

El main Threadestará en waitestado para siempre, por finallylo tanto , nunca será llamado ,

entonces la salida de la consola no print String: después wait()ofinally

De acuerdo con @Stephen C, el ejemplo anterior es uno de los 3er caso mencionados aquí :

Agregando algunas más posibilidades de bucle infinito en el siguiente código:

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

Caso 2: si la JVM se bloquea primero

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: ¿Cómo se bloquea un JVM?

Caso 6: si el finallybloque va a ser ejecutado por un demonio Thready se llama a todas las otras Threadssalidas que no sean demonios antes 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("-------------------------------------------------");
}

salida: Esto no imprime "finalmente", lo que implica que "Finalmente bloque" en "hilo de demonio" no se ejecutó

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

Considere el siguiente programa:

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

A partir de Java 1.8.162, el bloque de código anterior proporciona el siguiente resultado:

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

Esto significa que usar finallypara liberar objetos es una buena práctica como el siguiente código:

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

Eso es realmente cierto en cualquier idioma ... finalmente siempre se ejecutará antes de una declaración de devolución, sin importar dónde esté esa devolución en el cuerpo del método. Si ese no fuera el caso, el bloque finalmente no tendría mucho significado.

Además del punto sobre el retorno al reemplazar finalmente un retorno en el bloque try, lo mismo se aplica a una excepción. Un bloque finalmente que arroja una excepción reemplazará una devolución o excepción lanzada desde el bloque try.

finally ejecutará y eso es seguro.

finally no se ejecutará en los siguientes casos:

caso 1 :

Cuando estás ejecutando System.exit().

caso 2:

Cuando tu JVM / Thread se bloquea.

caso 3:

Cuando su ejecución se detiene en el medio manualmente.

1. Finalmente Block siempre se ejecuta. A menos que y hasta que exista la declaración System.exit () allí (primera declaración en el bloque finalmente).
2. Si system.exit () es la primera instrucción, finalmente el bloque no se ejecutará y el control saldrá del último bloque. Cada vez que la instrucción System.exit () ingresa finalmente en el bloque hasta que esa instrucción finalmente se ejecute y cuando aparece System.exit (), la fuerza de control sale completamente del bloque finalmente.