Does a finally block always get executed in Java?

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

Example code:

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

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

Output:

something is printed. 
0

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.

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.

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

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'

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

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.

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

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.

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

System.out.println("x value from foo() = " + foo());

...

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

Output:

x value in finally = 3
x value from foo() = 2

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

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.

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.

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.

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.

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

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

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

I am terribly late to answer here, but I am surprised that no one mentioned the Java debugger option to drop a stack frame. I am a heavy user of this feature in IntelliJ. (I am sure Eclipse and NetBeans has support for the same feature.)

If I drop stack frame from a the try or catch block that is followed by a finally block, the IDE will prompt me: "Shall I execute the finally block?" Obviously, this is an artificial runtime environment -- a debugger!

To answer your question, I would say you can only guarantee it runs if ignore when a debugger is attached, and (like others said) method something() does not (a) call Java method System.exit(int) or (b) C function exit(int) / abort() via JNI or (c) do something crazy like call kill -9 $PID on itself(!).

The accepted answer is true in nearly all aspects, but it is still only halve the truth at all (ok, 95% of the truth).

Assume the following code:

private final Lock m_Lock = new ReentrantLock();
…
public final SomeObject doSomething( final SomeObject arg )
{
  final SomeObject retValue;
  try
  {
    lock.lock();
    retValue = SomeObject( arg );
  }
  finally
  {
    out.println( "Entering finally block");
    callingAnotherMethod( arg, retValue );
    lock.unlock();
  }
  
  return retValue;
}
…
try
{
   final var result = doSomething( new SomeObject() );
}
catch( final StackOverflowError e ) { /* Deliberately ignored */ }

Calling the method doSomething() will cause a StackOverflowError nearly immediately.

And the lock will not be released!

But how could this happen when the finally block is always executed (with the exceptions already listed in the accepted answer)?

That is because there is no guarantee made that all statements in the finally block are really executed!

This would be obvious if there would be a call to System.exit() or a throws statement before the call to lock.unlock().

But there is nothing like that in the sample code …

Aside that the two other method calls in the finally block before the call to lock.unlock() will cause another StackOverflowError …

And voilà, the lock is not released!

Although the sample code as such is silly, similar patterns can be found a lot in many kinds of software. All works fine as long as nothing ugly happens in the finally block …

Funny fact is that it does not work in later versions of Java (meaning that in later versions, the lock was released …). No idea when and why this changed.

But you still have to make sure that the finally block always terminates normally, otherwise it might not matter if (that) it always get executed …