2506

Considering this code, can I be absolutely sure that the finally block always executes, no matter what something() is?

try {  
    something();  
    return success;  
}  
catch (Exception e) {   
    return failure;  
}  
finally {  
    System.out.println("I don't know if this will get printed out");
}
Anshul Sharma
  • 682
  • 3
  • 5
  • 20
jonny five
  • 25,492
  • 3
  • 18
  • 11

49 Answers49

2844

Yes, finally will be called after the execution of the try or catch code blocks.

The only times finally won't be called are:

  1. If you invoke System.exit()
  2. If you invoke Runtime.getRuntime().halt(exitStatus)
  3. If the JVM crashes first
  4. If the JVM reaches an infinite loop (or some other non-interruptable, non-terminating statement) in the try or catch block
  5. If the OS forcibly terminates the JVM process; e.g., kill -9 <pid> on UNIX
  6. If the host system dies; e.g., power failure, hardware error, OS panic, et cetera
  7. If the finally block is going to be executed by a daemon thread and all other non-daemon threads exit before finally is called
Ali Dehghani
  • 39,344
  • 13
  • 147
  • 138
jodonnell
  • 47,465
  • 10
  • 59
  • 65
  • 45
    Actually `thread.stop()` does not necessarily prevent `finally` block from being executed. – Piotr Findeisen Mar 30 '11 at 21:12
  • 195
    How about we say that the `finally` block will be called *after* the `try` block, and *before* control passes to the following statements. That's consistent with the try block involving an infinite loop and hence the finally block never actually being invoked. – Andrzej Doyle Sep 16 '11 at 11:24
  • By @andrzejDoyle definition, it will return `success` first before going to `finally` block. Is that correct? – dieend Apr 21 '13 at 07:44
  • 1
    @dieend: It will decide that the return value will be success, executes the finally block, then gives back control to the calling function. Nothing will be returned if the finally block throws. – Laurent LA RIZZA Jun 28 '13 at 05:00
  • 9
    there is also another case, when we use nested **try-catch-finally** blocks – ruhungry Mar 22 '14 at 20:39
  • 7
    also, finally block is not called in case of exception thrown by daemon thread. – Amrish Pandey Sep 11 '14 at 12:07
  • 1
    But effective java says otherwise. http://www.informit.com/articles/article.aspx?p=1216151&seqNum=7 – Binoy Babu Dec 14 '14 at 03:08
  • 1
    This is rather interesting that finally would be called when one re-throws his exception in catch() as new RuntimeException. – Mikhail Krutov Aug 16 '15 at 00:22
  • 15
    @BinoyBabu - That's about finalizer, not finally block – avmohan Jan 05 '17 at 10:17
  • 3
    What about **Runtime#halt** ? – gstackoverflow Mar 13 '17 at 08:35
  • 2
    @AmrishPandey "finally block is not called in case of exception thrown by daemon thread" - really?? [Citation Needed], I think? – SusanW Apr 25 '17 at 12:59
  • @SusanW http://javarevisited.blogspot.in/2012/03/what-is-daemon-thread-in-java-and.html?m=1 – Amrish Pandey Jun 05 '17 at 16:43
  • @SusanW https://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html – Amrish Pandey Jun 05 '17 at 16:45
  • 4
    @AmrishPandey The Oracle page doesn't mention daemons at all. The other (blogger) page discusses a JVM _terminating_, but fails to go on to show any difference vs a non-daemon thread. Reality is: on System.exit completion (incl shutdown hooks) or other termination, all threads just die where they are standing whether daemon or not: no finallys get executed either way. The blogger is incorrect where they note this as a difference ... try it yourself. – SusanW Jun 05 '17 at 18:21
  • 1
    @SusanW - Correct. The reason that the daemon thread is not executing `finally` in that example is reason 3). It is in an infinite loop. If the loop wasn't there, then it could also fail to execute the `finally` for reason 1). When `main` method returns (and there are no non-daemon threads) it executes `System.exit()` ... or the equivalent. Bottom line: daemon threads are NOT an exception to the reasons given by the Answer above. – Stephen C Aug 20 '17 at 01:16
  • 4
    Infinite loop is not really an exception to the "finally will be called when try block finishes" rule. Even with an infinite loop in the try block, the finally block still *will* execute ***when the try block finishes***, as usual - the try block just does not finish. This is not a special case. – Loduwijk Jan 03 '18 at 15:17
  • 2
    "The host system dies; eg. power failure, hardware error..." is not really an exception to the finally block rule either. That's like "will `return 1+1` always return 2?" "Not necessarily; a power loss can stop `return 1+1` from returning 2." ... not really a part of the answer. Same thing with #4, the `kill -9` example; it is sufficient for #4 and #5 both that #2 "JVM crash" is listed, which could be worded "JVM terminates abruptly" to better catch all situations. – Loduwijk Jan 03 '18 at 15:20
  • `finally` is also executed when a `StackOverflowError` is thrown. – MC Emperor Feb 28 '18 at 15:00
  • 1
    Java's`System.exit();` (like C#'s or PHP's) can be confusing for developers coming from other programming languages. In Python `sys.exit()` raises a (regular) `SystemExit` exception that can be catched. In Pascal `exit` is a regular control statement, and `finally` will be executed too. – Dávid Horváth May 03 '18 at 14:04
  • 2
    @MCEmperor, to piggy-back on this, although `finally` is executed even after a `StackOverflowError`, frames added to the stack within a `finally` block can cause an unexpected _additional_ `StackOverflowError`, leading to the remaining contents of the `finally` block being skipped. For this reason, `StackOverflowError` errors can be quite dangerous. We recently ran into a difficult issue with semaphores not being released in a `finally` block for this very reason. – Mike Hill Aug 01 '18 at 15:15
  • 2
    Q: Does it always? A: Yes, except... To me this means the accepted answer should be no. If there is exceptions to always, then its no. It may run most of the time. But not always. I am surprised I am one of few to react on this. – JugsteR Aug 14 '18 at 07:27
  • @JugsteR All of the cases when it doesn't is when something crazy happens like someone force killing the process, it entering an infinite loop, or the power going out. To me, if it behaves a certain way except in those most extreme of edge cases it's fine to say "yes always, except..." instead of "no". Actually, in the case of an infinite loop, it *would* still execute the finally, it's just that it never finishes what it's doing before it. – Captain Man Sep 13 '18 at 18:26
  • 1
    If the machine is suspended. If the kernel never again gives the JVM time to execute. There are probably many more edge cases when finally is not executed. This answer gives a good and easy to understand explanation. But it would be easier and more simple to say *"If the try block or try-catch block completes then the finally block is executed."* The JLS uses this same kind of language. – Anonymous Coward Oct 24 '18 at 23:38
  • Another one: When I debug using IntelliJ, if I drop stack frame inside a `try` block (that also has an associated `finally` block), I am asked by IntelliJ if I want to execute the `finally` block or not. I'm not sure if this is a standard Java debugger feature, or something IntelliJ developed themselves. – kevinarpe Dec 10 '20 at 12:17
593

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

Output:

finally trumps return. 
0
Kevin
  • 6,391
  • 1
  • 15
  • 13
  • 20
    FYI: In C# the behaviour is identical apart from the fact that replacing the statement in the `finally`-clause with `return 2;` is not allowed (Compiler-Error). – Alexander Pacha Oct 31 '13 at 08:08
  • 15
    Here is an important detail to be aware of: http://stackoverflow.com/a/20363941/2684342 – WoodenKitty Dec 03 '13 at 23:37
  • IF YOU ADD CATCH BLOCK, `error: missing return statement` – Harry Oct 26 '14 at 05:20
  • 21
    You can even add a return statement in the finally block itself, which will then override the previous return value. This also magically discards unhandled exceptions. At that point, you should consider refactoring your code. – Zyl Apr 15 '15 at 17:25
  • 9
    That does not really prove that finally trumps return. The return value is printed from the caller code. Doesn't seem to prove much. – Trimtab Jun 21 '16 at 04:20
  • @Trimtab, Yes, it's only answering the question as asked. [Tristan's answer](http://stackoverflow.com/a/20363941/1058366) clarifies that the value to return is evaluated, the `finally` block is run, and then control is returned to the caller. – Kevin Jun 21 '16 at 20:02
  • 22
    Sorry, but this is a demonstration not a proof. It is only a proof if you can show that this example always behaves this way on all Java platforms, AND that similar examples also always behave this way. – Stephen C Aug 20 '17 at 01:24
  • 4
    On a very off-topic side note, I'm _politically_ sure this print statement is gonna age like milk. – Julio Cezar Silva Aug 14 '20 at 16:20
405

Also, although it's bad practice, if there is a return statement within the finally block, it will trump any other return from the regular block. That is, the following block would return false:

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

Same thing with throwing exceptions from the finally block.

MooBob42
  • 4,075
  • 1
  • 13
  • 2
  • 100
    This is a REALLY bad practice. See http://stackoverflow.com/questions/48088/returning-from-a-finally-block-in-java for more info about why it's bad. – John Meagher Sep 16 '08 at 02:47
  • 23
    Agreed. A return within finally{} ignores any exception thrown in try{}. Scary! – neu242 Oct 22 '08 at 07:12
  • 1
    No matter what, I always have ONLY ONE `return` statement in my methods (which is at the end), well except when its `void`. That's what they taught me at school and I think it's a better practice too. – dominicbri7 Jul 07 '11 at 13:14
  • 8
    @dominicbri7 Why do you think it's a better practice? And why should it be different when the function/method is void? – corsiKa Jul 12 '11 at 20:26
  • 8
    For the same reason I NEVER use goto's in my C++ codes. I think multiple returns makes it harder to read and more difficult to debug (of course in really simple cases it doesn't apply). I guess that's just personnal preferrence and in the end you can achieve the same thing using either method – dominicbri7 Jul 13 '11 at 11:47
  • 16
    I tend to use a number of returns when some kind of exceptional case happens. Like if(there is a reason not to continue) return; – iHearGeoff Feb 22 '13 at 23:24
  • I interpret `finally` block as a shorthand for writing the same code at the end of each `catch` block: `catch (Exc exc) { doSome(); } catch (AnotherExc exc) { doSome(); } – MC Emperor Jun 28 '14 at 20:06
  • @MCEmperor Not the same, because as the answer states, if the `finally` block has a return statement, it will override the one in the `catch` block. You cannot do it with `catch`. – GregT May 31 '17 at 15:13
  • @MooBob42, should do it with embedded finallys – Pacerier May 10 '20 at 01:28
  • Very interesting example provided. – Misho Zhghenti Sep 20 '20 at 21:09
260

Here's the official words from the Java Language Specification.

14.20.2. Execution of try-finally and try-catch-finally

A try statement with a finally block is executed by first executing the try block. Then there is a choice:

  • If execution of the try block completes normally, [...]
  • If execution of the try block completes abruptly because of a throw of a value V, [...]
  • If execution of the try block completes abruptly for any other reason R, then the finally block is executed. Then there is a choice:
    • If the finally block completes normally, then the try statement completes abruptly for reason R.
    • If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and reason R is discarded).

The specification for return actually makes this explicit:

JLS 14.17 The return Statement

ReturnStatement:
     return Expression(opt) ;

A return statement with no Expression attempts to transfer control to the invoker of the method or constructor that contains it.

A return statement with an Expression attempts to transfer control to the invoker of the method that contains it; the value of the Expression becomes the value of the method invocation.

The preceding descriptions say "attempts to transfer control" rather than just "transfers control" because if there are any try statements within the method or constructor whose try blocks contain the return statement, then any finally clauses of those try statements will be executed, in order, innermost to outermost, before control is transferred to the invoker of the method or constructor. Abrupt completion of a finally clause can disrupt the transfer of control initiated by a return statement.

Kenster
  • 18,710
  • 21
  • 68
  • 90
polygenelubricants
  • 348,637
  • 121
  • 546
  • 611
167

In addition to the other responses, it is important to point out that 'finally' has the right to override any exception/returned value by the try..catch block. For example, the following code returns 12:

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

Similarly, the following method does not throw an exception:

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

While the following method does throw it:

public static int getMonthsInYear() {
    try {
        return 12;          
    }
    finally {
        throw new RuntimeException();
    }
}
MC Emperor
  • 17,266
  • 13
  • 70
  • 106
Eyal Schneider
  • 21,096
  • 4
  • 43
  • 73
  • 65
    It should be noted that the middle case is precisely the reason why having a return statement inside a finally block is absolutely horrible (it could hide any Throwable). – Dimitris Andreou May 13 '10 at 11:54
  • 2
    Who _doesn't_ want a surpressed `OutOfMemoryError`? ;) – RecursiveExceptionException Feb 07 '19 at 18:06
  • I tested it and it does suppress such an error (yipes!). It also generates a warning when I compile it (yay!). And you can work around it by defining a return variable and then using `return retVal` *after* the `finally` block, although that of course assumes that you suppressed some other exceptions because the code would not make sense otherwise. – Maarten Bodewes Dec 22 '19 at 16:02
124

Here's an elaboration of Kevin's answer. It's important to know that the expression to be returned is evaluated before finally, even if it is returned after.

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

Output:

X
finally trumps return... sort of
0
Community
  • 1
  • 1
WoodenKitty
  • 6,101
  • 8
  • 47
  • 70
  • 8
    Important to know. – Aminadav Glickshtein Jul 06 '18 at 12:06
  • Good to know, and makes sense as well. It seems that actually returning the value of return is what comes after `finally`. Calculating the return value (`printX()` here) still comes before it. – Albert Jun 26 '19 at 10:58
  • Nope. The code above should replace `System.out.println("finally trumps return... sort of");` with `System.out.print("finally trumps return in try"); return 42;` – Pacerier May 10 '20 at 01:21
123

I tried the above example with slight 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.");
    }
}

The above code outputs:

finally trumps return.
2

This is because when return i; is executed i has a value 2. After this the finally block is executed where 12 is assigned to i and then System.out out is executed.

After executing the finally block the try block returns 2, rather than returning 12, because this return statement is not executed again.

If you will debug this code in Eclipse then you'll get a feeling that after executing System.out of finally block the return statement of try block is executed again. But this is not the case. It simply returns the value 2.

Jared Rummler
  • 35,743
  • 18
  • 127
  • 142
vibhash
  • 1,239
  • 1
  • 9
  • 3
  • 11
    This example is awesome, it adds something that hasn't been mentioned in dozens finally related threads. I think barely any developer will know this. – HopefullyHelpful Sep 08 '16 at 09:11
  • 5
    What if `i` was not a primitive, but an Integer object. – Yamcha Sep 09 '16 at 20:50
  • I am having a hard time understanding this case. https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.17 says that, "A return statement with an Expression attempts to transfer control to the invoker of the method or lambda body that contains it.... If evaluation of the Expression completes normally, producing a value V.." What I could guess from this statement is- it seems that return doesn't evaluate the expression again once it evaluates value V, that's why changed i doesn't affect the returned value, correct me. – meexplorer Nov 15 '16 at 18:21
  • But I coudn't found any proof regarding this, where is it mentioned that return doesn't evaluate the expression again. – meexplorer Nov 15 '16 at 18:27
  • 1
    @meexplorer a bit late, but it is explained in [JLS 14.20.2. Execution of try-finally and try-catch-finally](https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.20.2-100-C) - worded a bit complicated, [14.17. The return Statement](https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.17-430) must also be read – user85421 May 17 '17 at 19:18
  • @ Yamcha It would still be same – Ngupta Jun 05 '17 at 12:35
  • I believe that if you added a return statement to the finally block, the value returned would be 12, not 2. The example basically shows that the finally block is pushed onto the call stack exactly the same as calling a method - that makes a local copy of i, which reverts to 2 after the stack is popped. – Rodney P. Barbati May 14 '18 at 17:05
53

That is the whole idea of a finally block. It lets you make sure you do cleanups that might otherwise be skipped because you return, among other things, of course.

Finally gets called regardless of what happens in the try block (unless you call System.exit(int) or the Java Virtual Machine kicks out for some other reason).

Chris Cooper
  • 16,224
  • 8
  • 50
  • 70
42

A logical way to think about this is:

  1. Code placed in a finally block must be executed whatever occurs within the try block
  2. So if code in the try block tries to return a value or throw an exception the item is placed 'on the shelf' till the finally block can execute
  3. Because code in the finally block has (by definition) a high priority it can return or throw whatever it likes. In which case anything left 'on the shelf' is discarded.
  4. The only exception to this is if the VM shuts down completely during the try block e.g. by 'System.exit'
Garth Gilmour
  • 10,524
  • 5
  • 22
  • 34
  • 10
    Is this just "a logical way to think about it" or is it really how the finally block is intended to work according to the specifications ? A link to a Sun resource would be very interesting in here. – matias May 26 '10 at 19:27
21

finally is always executed unless there is abnormal program termination (like calling System.exit(0)..). so, your sysout will get printed

shyam
  • 8,153
  • 4
  • 23
  • 40
18

No, not always one exception case is// System.exit(0); before the finally block prevents finally to be executed.

  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");
        }
    }
}
Ram
  • 3,270
  • 4
  • 21
  • 48
Rajendra Jadi
  • 179
  • 1
  • 5
18

The finally block is always executed unless there is abnormal program termination, either resulting from a JVM crash or from a call to System.exit(0).

On top of that, any value returned from within the finally block will override the value returned prior to execution of the finally block, so be careful of checking all exit points when using try finally.

YCF_L
  • 49,027
  • 13
  • 75
  • 115
user9189
  • 239
  • 1
  • 3
18

Also a return in finally will throw away any exception. http://jamesjava.blogspot.com/2006/03/dont-return-in-finally-clause.html

James A. N. Stauffer
  • 2,581
  • 3
  • 21
  • 31
12

Finally is always run that's the whole point, just because it appears in the code after the return doesn't mean that that's how it's implemented. The Java runtime has the responsibility to run this code when exiting the try block.

For example if you have the following:

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

The runtime will generate something like this:

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

If an uncaught exception is thrown the finally block will run and the exception will continue propagating.

Motti
  • 99,411
  • 44
  • 178
  • 249
10

Because a finally block will always be called unless you call System.exit() (or the thread crashes).

Jay Riggs
  • 51,115
  • 9
  • 133
  • 146
10

This is because you assigned the value of i as 12, but did not return the value of i to the function. The correct code is as follows:

public static int test() {
    int i = 0;
    try {
        return i;
    } finally {
        i = 12;
        System.out.println("finally trumps return.");
        return i;
    }
}
Ankush soni
  • 1,325
  • 1
  • 13
  • 29
Wasim
  • 101
  • 1
  • 2
10

Answer is simple YES.

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

OUTPUT:

catch
finally
Meet Vora
  • 2,483
  • 1
  • 14
  • 29
10

Yes it will get called. That's the whole point of having a finally keyword. If jumping out of the try/catch block could just skip the finally block it was the same as putting the System.out.println outside the try/catch.

Mendelt
  • 34,619
  • 6
  • 71
  • 94
9

Concisely, in the official Java Documentation (Click here), it is written that -

If the JVM exits while the try or catch code is being executed, then the finally block may not execute. Likewise, if the thread executing the try or catch code is interrupted or killed, the finally block may not execute even though the application as a whole continues.

bikz05
  • 1,325
  • 11
  • 16
9

NOT ALWAYS

The Java Language specification describes how try-catch-finally and try-catch blocks work at 14.20.2
In no place it specifies that the finally block is always executed. But for all cases in which the try-catch-finally and try-finally blocks complete it does specify that before completion finally must be executed.

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

The JLS does not guarantee that FIN is executed after CODE. The JLS guarantees that if CODE and NEXT are executed then FIN will always be executed after CODE and before NEXT.

Why doesn't the JLS guarantee that the finally block is always executed after the try block? Because it is impossible. It is unlikely but possible that the JVM will be aborted (kill, crash, power off) just after completing the try block but before execution of the finally block. There is nothing the JLS can do to avoid this.

Thus, any software which for their proper behaviour depends on finally blocks always being executed after their try blocks complete are bugged.

return instructions in the try block are irrelevant to this issue. If execution reaches code after the try-catch-finally it is guaranteed that the finally block will have been executed before, with or without return instructions inside the try block.

Anonymous Coward
  • 3,045
  • 20
  • 37
8

Yes, it will. No matter what happens in your try or catch block unless otherwise System.exit() called or JVM crashed. if there is any return statement in the block(s),finally will be executed prior to that return statement.

Karthikeyan
  • 2,064
  • 3
  • 24
  • 44
8

Yes, finally block is always execute. Most of developer use this block the closing the database connection, resultset object, statement object and also uses into the java hibernate to rollback the transaction.

Gautam Viradiya
  • 457
  • 7
  • 11
8

I tried this, It is single threaded.

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 will be on wait state forever, hence finally will never be called,

so console output will not print String: after wait() or finally

Agreed with @Stephen C, the above example is one of the 3rd case mention here:

Adding some more such infinite loop possibilities in following code:

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

Case 2: If the JVM crashes first

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: How do you crash a JVM?

Case 6: If finally block is going to be executed by daemon Thread and all other non-daemon Threads exit before finally is called.

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

output: This does not print "finally" which implies "Finally block" in "daemon thread" did not execute

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
lue
  • 399
  • 4
  • 16
dkb
  • 3,238
  • 3
  • 26
  • 41
8

Adding to @vibhash's answer as no other answer explains what happens in the case of a mutable object like the one below.

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

Will output

sbupdated 
Neuron
  • 3,776
  • 3
  • 24
  • 44
8

finally is always executed and before returning x's (calculated) value.

System.out.println(foo());

....

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

Output:

3
2
baitmbarek
  • 2,252
  • 4
  • 15
  • 26
hellzone
  • 4,413
  • 18
  • 69
  • 118
7

In addition to the point about return in finally replacing a return in the try block, the same is true of an exception. A finally block that throws an exception will replace a return or exception thrown from within the try block.

Alex Miller
  • 65,227
  • 26
  • 112
  • 160
7

Yes It will. Only case it will not is JVM exits or crashes

abhig
  • 740
  • 1
  • 10
  • 22
7

finally will execute and that is for sure.

finally will not execute in below cases:

case 1 :

When you are executing System.exit().

case 2 :

When your JVM / Thread crashes.

case 3 :

When your execution is stopped in between manually.

L Joey
  • 125
  • 2
  • 7
Utkash Bhatt
  • 133
  • 3
  • 10
7

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

As of Java 1.8.162, the above code block gives the following output:

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

this means that using finally to free up objects is a good practice like the following code:

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.
    }
}
sam
  • 1,417
  • 1
  • 20
  • 39
  • Shouldn't it be `sb.setLength(0)` in finally? – user7294900 Sep 05 '18 at 06:38
  • sb.setLength(0) will just empty the data in the StringBuffer. So, sb = null will disassociate the object from the reference. – sam Sep 05 '18 at 17:16
  • Shouldn't "xyz" be printed twice in the output? Since the function was called twice, why "finally" was only once? – fresko Feb 13 '19 at 10:22
  • @fresko : finallly is definitely called twice but when it comes to the output in the console it will only show once because of the return statement. You can run the program and see the output, and after that add another statement `System.out.println(sb.toString());` – sam Feb 13 '19 at 15:21
  • 2
    This isn't a good practice. That finally block with `sb = null;` just adds unneeded code. I understand that you mean that a `finally` block is a good place to free resources like a database connection or something like that, but have in mind that your example could confuse newcomers. – Roc Boronat Feb 15 '19 at 23:58
  • 1
    @Samim Thanks, I added the lines `System.out.println("---AGAIN2---");` `System.out.println(sb);` and it's more clear now. As it was, the output was against your thesis :p I also added to your answer, but the edit must be accepted by a moderator or somebody like that. Else you can add them – fresko Feb 19 '19 at 13:08
6

I was very confused with all the answers provided on different forums and decided to finally code and see. The ouput is :

finally will be executed even if there is return in try and catch block.

try {  
  System.out.println("try"); 
  return;
  //int  i =5/0;
  //System.exit(0 ) ;
} catch (Exception e) {   
  System.out.println("catch");
  return;
  //int  i =5/0;
  //System.exit(0 ) ;
} finally {  
   System.out.println("Print me FINALLY");
}

Output

try

Print me FINALLY

  1. If return is replaced by System.exit(0) in try and catch block in above code and an exception occurs before it,for any reason.
Community
  • 1
  • 1
milton
  • 69
  • 1
  • 3
6
  1. Finally Block always get executed. Unless and until System.exit() statement exists there (first statement in finally block).
  2. If system.exit() is first statement then finally block won't get executed and control come out of the finally block. Whenever System.exit() statement gets in finally block till that statement finally block executed and when System.exit() appears then control force fully come out of the finally block.
Avinash Pande
  • 1,280
  • 17
  • 17
  • 2
    This has been answered many times, so which new information does your answer add? – Tom May 20 '17 at 12:19
6

If you don't handle exception, before terminating the program, JVM executes finally block. It will not executed only if normal execution of program will fail mean's termination of program due to these following reasons..

  1. By causing a fatal error that causes the process to abort.

  2. Termination of program due to memory corrupt.

  3. By calling System.exit()

  4. If program goes into infinity loop.

Vikas Suryawanshi
  • 494
  • 1
  • 5
  • 12
6

Yes, because no control statement can prevent finally from being executed.

Here is a reference example, where all code blocks will be executed:

| x | Current result | Code 
|---|----------------|------ - - -
|   |                |     
|   |                | public static int finallyTest() {
| 3 |                |     int x = 3;
|   |                |     try {
|   |                |        try {
| 4 |                |             x++;
| 4 | return 4       |             return x;
|   |                |         } finally {
| 3 |                |             x--;
| 3 | throw          |             throw new RuntimeException("Ahh!");
|   |                |         }
|   |                |     } catch (RuntimeException e) {
| 4 | return 4       |         return ++x;
|   |                |     } finally {
| 3 |                |         x--;
|   |                |     }
|   |                | }
|   |                |
|---|----------------|------ - - -
|   | Result: 4      |

In the variant below, return x; will be skipped. Result is still 4:

public static int finallyTest() {
    int x = 3;
    try {
        try {
            x++;
            if (true) throw new RuntimeException("Ahh!");
            return x; // skipped
        } finally {
            x--;
        }
    } catch (RuntimeException e) {
        return ++x;
    } finally {
        x--;
    }
}

References, of course, track their status. This example returns a reference with value = 4:

static class IntRef { public int value; }
public static IntRef finallyTest() {
    IntRef x = new IntRef();
    x.value = 3;
    try {
        return x;
    } finally {
        x.value++; // will be tracked even after return
    }
}
Dávid Horváth
  • 3,376
  • 1
  • 18
  • 29
6

That's actually true in any language...finally will always execute before a return statement, no matter where that return is in the method body. If that wasn't the case, the finally block wouldn't have much meaning.

Scott Dorman
  • 40,345
  • 11
  • 74
  • 107
5

The finally block will not be called after return in a couple of unique scenarios: if System.exit() is called first, or if the JVM crashes.

Let me try to answer your question in the easiest possible way.

Rule 1 : The finally block always run (Though there are exceptions to it. But let's stick to this for sometime.)

Rule 2 : the statements in the finally block run when control leaves a try or a catch block.The transfer of control can occur as a result of normal execution ,of execution of a break , continue, goto or a return statement, or of a propogation of an exception.

In case of a return statement specifically (since its captioned), the control has to leave the calling method , And hence calls the finally block of the corresponding try-finally structure. The return statement is executed after the finally block.

In case there's a return statement in the finally block also, it will definitely override the one pending at the try block , since its clearing the call stack.

You can refer a better explanation here : http://msdn.microsoft.com/en-us/.... the concept is mostly same in all the high level languages.

Sandip Solanki
  • 632
  • 1
  • 8
  • 13
5

Yes, it is written here

If the JVM exits while the try or catch code is being executed, then the finally block may not execute. Likewise, if the thread executing the try or catch code is interrupted or killed, the finally block may not execute even though the application as a whole continues.

5

try- catch- finally are the key words for using exception handling case.
As normal explanotory

try {
     //code statements
     //exception thrown here
     //lines not reached if exception thrown
} catch (Exception e) {
    //lines reached only when exception is thrown
} finally {
    // always executed when the try block is exited
    //independent of an exception thrown or not
}

The finally block prevent executing...

  • When you called System.exit(0);
  • If JVM exits.
  • Errors in the JVM
Poorna Senani Gamage
  • 1,170
  • 1
  • 15
  • 25
4

Try this code, you will understand the code in finally block is get executed after return statement.

public class TestTryCatchFinally {
    static int x = 0;

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

    public static int f1(){
        try{
            x = 1;
            return x;
        }finally{
            x = 2;
        }
    }

    public static int f2(){
        return x;
    }
}
eric2323223
  • 3,280
  • 6
  • 35
  • 54
4

Finally block always execute whether exception handle or not .if any exception occurred before try block then finally block will not execute.

Rohit Chugh
  • 109
  • 1
  • 2
4

If an exception is thrown, finally runs. If an exception is not thrown, finally runs. If the exception is caught, finally runs. If the exception is not caught, finally runs.

Only time it does not run is when JVM exits.

Bhushan
  • 16,055
  • 24
  • 96
  • 132
3

Because the final is always be called in whatever cases you have. You don't have exception, it is still called, catch exception, it is still called

vodkhang
  • 18,281
  • 10
  • 73
  • 109
3

Consider this in a normal course of execution (i.e without any Exception being thrown): if method is not 'void' then it always explicitly returns something, yet, finally always gets executed

Gala101
  • 454
  • 5
  • 13
3

finally can also be exited prematurely if an Exception is thrown inside a nested finally block. The compiler will warn you that the finally block does not complete normally or give an error that you have unreachable code. The error for unreachable code will be shown only if the throw is not behind a conditional statement or inside a loop.

try{
}finally{
   try{
   }finally{
      //if(someCondition) --> no error because of unreachable code
      throw new RunTimeException();
   }
   int a = 5;//unreachable code
}
lue
  • 399
  • 4
  • 16
HopefullyHelpful
  • 1,529
  • 3
  • 17
  • 36
  • 1
    Just noting that this is completely normal behavior. Any/all code exits prematurely if an exception is thrown. This is no different than an exception thrown anywhere else. There is no special rule in the spec that says "exceptions cannot be used inside a finally block." Because of this, I even misunderstood your answer at first and almost gave -1, until I reread it a couple times. – Loduwijk Jan 03 '18 at 15:05
  • Well, but how is a return different from a throw? If you return then the block should return but in a finally block, the return will be postponed and there are some weird exception for return, so it isn't clear that finally handles throw in a normal way. That is the main reason why I wrote this back then. Also throw in a try or catch block won't hinder the finally block from execution, so ofc. one might expect that when you throw in a finally block it still executes. – HopefullyHelpful Jan 03 '18 at 20:56
  • 1
    "how is return different from throw?" In a few ways, none of which are relevant here. In a finally block, return is not postponed, or did you mean the return in the try-block being postponed until after finally-block executes (in which case, yes that is true)? Either way, the same holds for thrown exceptions. No matter what happens in a `try`, when the end of `try` is reached, the control passes to `finally`, then all the same rules apply within the `finally` (with any try/catch inside of finally operating as they usually would). – Loduwijk Jan 04 '18 at 00:24
  • 2
    I am not saying your answer is wrong or useless or anything like that. It is technically correct. I merely noted that the behavior you describe is nothing that breaks the try/finally rule which is simply "No matter what happens in `try/catch`, once they are done control flow ***will*** pass to the finally block" The try/finally guarantee is essentially nothing more, nothing less than that. Within any block, be it try/catch/finally or otherwise, you can within it nest other try/catch/finally blocks as you suggest. Indeed, some people are unaware of that. – Loduwijk Jan 04 '18 at 00:29
3

Same with the following code:

static int f() {
    while (true) {
        try {
            return 1;
        } finally {
            break;
        }
    }
    return 2;
}

f will return 2!

dibo
  • 67
  • 2
3

Yes it will always called but in one situation it not call when you use System.exit()

try{
//risky code
}catch(Exception e){
//exception handling code
}
finally(){
//It always execute but before this block if there is any statement like System.exit(0); then this block not execute.
}
2

finally block is executed always even if you put a return statement in the try block. The finally block will be executed before the return statement.

Sabrina
  • 394
  • 3
  • 16
2

Finally is always called at the end

when you try, it executes some code, if something happens in try, then catch will catch that exception and you could print some mssg out or throw an error, then finally block is executed.

Finally is normally used when doing cleanups, for instance, if you use a scanner in java, you should probably close the scanner as it leads to other problems such as not being able to open some file

2

Here are some conditions which can bypass a finally block:

  1. If the JVM exits while the try or catch code is being executed, then the finally block may not execute. More on sun tutorial
  2. Normal Shutdown - this occurs either when the last non-daemon thread exits OR when Runtime.exit() (some good blog). When a thread exits, the JVM performs an inventory of running threads, and if the only threads that are left are daemon threads, it initiates an orderly shutdown. When the JVM halts, any remaining daemon threads are abandoned finally blocks are not executed, stacks are not unwound the JVM just exits. Daemon threads should be used sparingly few processing activities can be safely abandoned at any time with no cleanup. In particular, it is dangerous to use daemon threads for tasks that might perform any sort of I/O. Daemon threads are best saved for "housekeeping" tasks, such as a background thread that periodically removes expired entries from an in-memory cache (source)

Last non-daemon thread exits example:

public class TestDaemon {
    private static Runnable runnable = new Runnable() {
        @Override
        public void run() {
            try {
                while (true) {
                    System.out.println("Is alive");
                    Thread.sleep(10);
                    // throw new RuntimeException();
                }
            } catch (Throwable t) {
                t.printStackTrace();
            } finally {
                System.out.println("This will never be executed.");
            }
        }
    };

    public static void main(String[] args) throws InterruptedException {
        Thread daemon = new Thread(runnable);
        daemon.setDaemon(true);
        daemon.start();
        Thread.sleep(100);
        // daemon.stop();
        System.out.println("Last non-daemon thread exits.");
    }
}

Output:

Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Last non-daemon thread exits.
Is alive
Is alive
Is alive
Is alive
Is alive
Mike
  • 17,033
  • 22
  • 85
  • 113
1

try-with-resoruce example

static class IamAutoCloseable implements AutoCloseable {
    private final String name;
    IamAutoCloseable(String name) {
        this.name = name;
    }
    public void close() {
        System.out.println(name);
    }
}

@Test
public void withResourceFinally() {
    try (IamAutoCloseable closeable1 = new IamAutoCloseable("closeable1");
         IamAutoCloseable closeable2 = new IamAutoCloseable("closeable2")) {
        System.out.println("try");
    } finally {
        System.out.println("finally");
    }
}

Test output:

try
closeable2
closeable1
finally
Youngrok Ko
  • 123
  • 1
  • 8