Java 8 SE: Finally block of a method is running before entering the method

Question

On page 359 of the Book: Java - How to Program - 10th Edition. Deitel explains the treatment of Java exceptions. It exemplifies the question with the following code:

public class UsingExceptions {
   public static void main(String[] args) {
      try {
         throwException(); 
      } 
      catch (Exception exception) { // exception thrown by throwException
         System.err.println("4 - Exception handled in main");
      } 

      doesNotThrowException();
   }

   // demonstrate try...catch...finally
   public static void throwException() throws Exception {
      try { // throw an exception and immediately catch it
         System.out.println("1 - Method throwException");
         throw new Exception(); // generate exception
      } 
      catch (Exception exception) { // catch exception thrown in try
         System.err.println(
            "2 - Exception handled in method throwException");
         throw exception; // rethrow for further processing

         // code here would not be reached; would cause compilation errors

      } 
      finally { // executes regardless of what occurs in try...catch
         System.err.println("3 - Finally executed in throwException");  
      }                                                             

      // code here would not be reached; would cause compilation errors
   } 

   // demonstrate finally when no exception occurs
   public static void doesNotThrowException() {
      try { // try block does not throw an exception
         System.out.println("5 - Method doesNotThrowException");
      } 
      catch (Exception exception) { // does not execute
         System.err.println(exception);
      }
      finally { // executes regardless of what occurs in try...catch     
         System.err.println("6 - Finally executed in doesNotThrowException");
      }                                                                  
 
      System.out.println("7 - End of method doesNotThrowException");
   } 
} 

In the book, Deitel agrees with me that the logical sequence of this code is:

1 - Method throwException
2 - Exception handled in method throwException
3 - Finally executed in throwException
4 - Exception handled in main
5 - Method doesNotThrowException
6 - Finally executed in doesNotThrowException
7 - End of method doesNotThrowException

However, when executing the code described in the book in Eclipse, Java inverts line 6 with line 5 and the result is like this:

1 - Method throwException
2 - Exception handled in method throwException
3 - Finally executed in throwException
4 - Exception handled in main
6 - Finally executed in doesNotThrowException
5 - Method doesNotThrowException
7 - End of method doesNotThrowException

That is, Java is calling the block finally of the method doesNotThrowException before entering the method. Someone can explain why?

Answer 1

What is happening is not that the finally is executed before the try, rather that System.out and System.err are not being synchronized. In this case, while your app is writing first on System.out, the result of System.err is appearing first on your terminal.

On the Java side, when you run a CLI application it tries to find and configure the outputs for the streams pattern stdout and stderr the environment in which the application is running.

While both System.out and System.err do flush automatic of their respective buffers every line break, what happens after that is out of JVM control.

In the common case, when you run your application on a shell interactive, these streams are connected to the text terminal where the shell is running. These components in turn interact directly or indirectly with operating system Apis to display the end result to the user.

There is no guarantee of synchronization between stderr and stdout. Flush the stdout before the stderr is no guarantee that your terminal will display the contents of stdout first. These components out of control of your application may be using buffers own, multiple threads, Apis connected to GPU and various other tricks to process and display streams efficiently. Maintain the streams synchronized can be quite costly, and by default most environments do not do this.

For this type of exercise it is worth using a single stream. In case you can replace calls to System.err for System.out.

Alternatively you can investigate if there is any way to configure your terminal to synchronize the streams. For example, the OP mentioned that it is using an old version of Eclipse. In modern versions there is already an option to synchronize streams in accordance with that answer in Soen.