I understand what the "finally" keyword is used for in various languages, however, I struggle to understand why you would use it outside of there being a formatting preference in taste.

For instance, in PHP:

try {

  possibleErrorThrownFunction();

}

catch (CustomException $customException) {

  // handle custom error

}

catch (Exception $exception) {

  // handle the error

}

finally {

  // run this code every single time regardless of error or not

}

What's the difference between what this code is doing and this?

try {

  possibleErrorThrownFunction();

}

catch (CustomException $customException) {

  // handle custom error

}

catch (Exception $exception) {

  // handle the error

}



// run this code every single time regardless of error or not

Doesn't that last line always get run anyway due to the error being caught? In which case, there is no case to really use finally unless you just want to maintain a code-style formatting?

An example of a case where a finally statement is necessary and distinct from just putting code after try/catch statements would be helpful if I am missing something here.

Short Answer

Finally blocks are guaranteed to run no matter what happens inside of the try and catch blocks, before allowing the program to crash.

This is sort of explained here: https://www.php.net/manual/en/language.exceptions.php though the explanation isn't particularly detailed.

Some More Detail

One example that comes to the top of my head is if you are dealing with input/output streams or something similar that has to be closed after use in order to avoid a memory leak. To use your example:

try {

  memoryUser.startReading(someFileOrSomething);

}

catch (CustomException $customException) {

  // handle custom error

}

catch (Exception $exception) {

  // handle the error

  invisibleBug.whoops(); // i.e. something goes wrong in this block

}



memoryUser.Close(); // because something went wrong in the catch block,

                    // this never runs, which, in this case, causes a memory leak

In this case, wrapping the memoryUser.Close(); in a finally block would ensure that that line would run before the rest of the program exploded, preventing the memory leak even in an otherwise catastrophic failure.

TL;DR

So a lot of the time, people put the finally block there to ensure an important line runs, even if they overlooked something in the catch blocks. This is how I've always seen it used.

Hopefully this helps :)

finally is more than syntactic sugar. It's all about the return flow of the call stack.

Besides the differences in the control flow, it is always considered good practise to put the cleanup for whatever you tried in the try block in a finally statement to ensure the cleanup is also done when your try fails.

Put together what belongs together. People like clean code.

Here are some things finally enables you to do, which code below a try/catch cannot:

1. 
   

   finally will always run, even when your catch blows up in a fatal error. The only other ways to achieve this are to implement a global error handler.

   
   
   

   finally helps you to keep the cleanup code in place.

   
   
   

    

   
   


2. 
   

   finally { throw new OverrideException(); } causes PHP to override all exceptions thrown in another catch block with the newly thrown exception in the finally branch. Code after the try/catch cannot be reached when you throw a new Exception inside a try/catch block.

   
   
   

    

   
   


3. 
   

   finally { return $sth; } inside a function causes PHP to forget all thrown exceptions in this function. It also overrides the return value from a try/catch block.

   
   
   

   Cited from a comment from (php at marcuspope dot com) in the PHP manual:

   
   
   

   
   

   Using a return statement inside a finally block will override any other return statement or thrown exception from the try block and all defined catch blocks. Code execution in the parent stack will continue as if the exception was never thrown.

   
   
   

   Frankly this is a good design decision because it means I can optionally dismiss all thrown exceptions from 1 or more catch blocks in one place, without having to nest my whole try block inside an additional (and otherwise needless) try/catch block.

   
   
   

   This is the same behavior as Java, whereas C# throws a compile time error when a return statement exists inside a finally block. So I figured it was worth pointing out to PHP devs who may not have any exposure to finally blocks or how other languages do it.

   
   
   

   <?php 
   
   function asdf()
   
   {
   
       try {
   
           throw new Exception('error');
   
       }
   
        catch(Exception $e) {
   
           echo "An error occurred";
   
           throw $e;
   
       }
   
       finally {
   
           // This overrides the exception as if it were never thrown
   
           return "nException erased";
   
       }
   
   } 
   
   try {
   
     echo asdf();
   
   }
   
   catch(Exception $e) {
   
      echo "nResult: " . $e->getMessage();
   
   }
   
   ?>
   
   

   
   

   
   

What's special about a finally {} block is that it will (almost) always run.

It will run if the code in the try {} block completes successfully.

It will run if the code in the try {} block throws an exception that was caught by a catch {}. (The finally {} runs after the catch {}.)

It will run if the code in the try {} block throws an exception that wasn't handled by any catch {} block, or if there weren't any at all. (The finally {} block runs before the exception is propagated to the caller.)

It will run if the code in the try {} block throws an exception, and the code in the catch {} throws another exception (or rethrows the same exception).

It will even run if the code in the try {} block, or in a catch {} block, uses return. (Just as with an uncaught exception, the finally {} runs before the function actually returns.) It can even use return itself, and its return value will override the other block's return value!

The only situation where a finally {} block won't run is if the entire process is destroyed, e.g. by calling exit() or die().