There are a lot of people on the Internet to discuss the exception capture mechanism in Java try...catch...finally The finally statement in the block is bound to be executed? A lot of people say no, of course their answer is correct, after I experiment, there are at least two cases in which the finally statement is not executed: (1) The Try statement is not executed, as returned before the try statement, so that the finally statement will not execute, This also shows that the necessary rather than sufficient condition for the finally statement to be executed is that the corresponding try statement must be executed. (2) There is system.exit (0) in the try block, such a statement, System.exit (0), terminates the Java Virtual Machine JVM, even the JVM is stopped, all is finished, and the finally statement is not executed. Of course there are many people who explore the relationship between the execution of the finally statement and the return, rather confusing, wondering if the finally statement is executed before the return of the try or after? I am also a confused, I think their statement is not correct, I think it should be: The finally statement is executed after the return statement of the try, return returned before the execution. This kind of argument is a bit contradictory, perhaps I am not very clear, the following I give some of the results of their own experiments and examples to support, there are any questions to welcome the proposed. 1. The finally statement executes after the return statement is executed. public class FinallyTest1 {public static void main (string[] args) {System.out.println (test1 ());} public static int test 1 () {int b =, try {System.out.println ("try Block"), return B + =,} catch (Exception e) {System.out.println ("catch Block "); } finally {System.out.println ("finally block"), if (b >) {System.out.println ("b>25, B =" + B);}} return b; The result of the run is: try block finally block b>25, b = 100 100 indicates that the return statement has been executed and then executes the finally statement, notNot return directly, but wait until the finally statement is finished and then return the result. If this example is not considered sufficient to illustrate the situation, add an example below to reinforce the conclusion: public class FinallyTest1 {public static void main (string[] args) { System.out.println (test11 ()); public static String test11 () {try {System.out.println ("try Block"); return test12 ();} finally {System.out.println (" Finally block "); }} public static String test12 () {System.out.println ("return statement"), return "after Return";}} The result is: Try block return statement finally block after return indicates that the return statement in the try was executed first but not immediately returned Wait until the finally execution is over, and here you might think: if there is a return statement in Finally, is it just return, and the return in the try cannot be returned? Look underneath. 2. The return statement in the finally block overrides return in the try block. public class FinallyTest2 {public static void main (string[] args) {System.out.println (Test2 ());} public static int test 2 () {int b =, try {System.out.println ("try Block"), return B + =,} catch (Exception e) {System.out.println ("catch Block "); } finally {System.out.println ("finally block"), if (b >) {System.out.println ("b>25, B =" + b);} return 200; }//return B; }} The result is: Try block finally block b>25, B = 100 200 This shows that the return in finally returns directly, regardless of whether there is a return statement in the try, there is a small detail to note, Finally, plus return, finally the outside of the return B becomes an unreachable statement, that is, can never be executed to, so need to comment out or the compiler error. Here you may think: if there is no return statement in Finally, but modified the value of B, then return in the try is the modified value or the original value? Look underneath. 3. If no return statement overrides the return value in the finally statement, the original return value may change or be unchanged because of the modification in the finally. Test case 1:public class FinallyTest3 {public static void main (string[] args) {System.out.println (Test3 ()); T test3 () {int b =, try {System.out.println ("try Block"), return B + =,} catch (Exception e) {System.out.println ( "Catch block"); } finally {System.out.println ("finally block"), if (b >) {System.out.println ("b>25, B =" + b);} b = 150; } return 2000; The result of the operation is: try block finally block b>25, B = 100 test case 2: import java.util.*; public class FinallyTest6 {public static void main (string[] args) {System.out.println (Getmap (). Get ("KEY"). toString ()); } public static map<string, string> Getmap () {map<string, STRING> Map = new hashmap<string, string> (); Map.put ("KEY", "INIT"); try {map.put ("key", "Try"), return map,} catch (Exception e) {map.put ("key", "Catch"),} finally {Map.put ("key", "FINA Lly "); Map = null; } return map; }} The result is: finally why test Case 1 in the finally in the B = 150, and did not play a role in the test Case 2 finally of the Map.put ("KEY", "finally"), the function and map = NULL; but it didn't work? This is the question of whether Java is a value or a transmission address, specifically, please see a selection of 30 Java pen Questions answered, there is a detailed answer, in simple terms: there is only a value in Java is not transmitted, which is why map = null This sentence does not work. This also indicates that the return statement is a return statement in a try instead of a finally outside of return B; If you do not believe it, you can try it and return B; instead, return 294 will have no effect on the original result. Here you may want to think: is not every time the return must be a try in the return statement? So finally the return B is not a bit of a function? Please look below. 4. The return statement in the try block will not be executed in the case of an exception, so it returns which one to see. public class FinallyTest4 {public static void main (string[] args) {System.out.println (test4 ());} public static int test 4 () {int b =, try {System.out.println ("try block"), B = b/0; return b + =,} catch (Exception e) {b + = 15; System.out.println ("Catch block"); } finally {System.out.println ("finally block"), if (b >) {System.out.println ("b>25, B = "+ b);} B + = 50; } return 204; The result of the run is: try block catch block finally block b>25, B = 35 85 here because a 0 exception occurred before the return, the return in the try is not executed, but the catch that catches the exception is then executed Statement and the final finally statement, when both changes to B affect the final return value, then return b; it works. Of course if you change the return B to return 300 or something, the last one is 300, which is beyond doubt. There may be another question here: What if there is a return statement in the catch? Of course, only in the case of exceptions can be executed, then the finally before the return? Look underneath. 5. When an exception occurs, the return execution in the catch is exactly the same as the execution of return in the try when no exception occurs. public class FinallyTest5 {public static void main (string[] args) {System.out.println (TEST5 ());} public static int test 5 () {int b =, try {System.out.println ("try block"), B = b/0; return b + =,} catch (Exception e) {System.out.prin Tln ("Catch block"); Return B + = 15; } finally {System.out.println ("finally block"), if (b >) {System.out.println ("b>25, B =" + b);} B + = 50; }//return B; The result of the run is as follows: Try block catch block finally block b>25, B = 35 35 indicates that after an exception occurs, the return statement in the catch executes first, the return value is determined, then the finally block executes and the catch is executed. Return, finally the change to B has no effect on the return value, the same reason as before, that is, the situation is exactly the same as the return statement execution in try. Final Summary: FThe statement of the inally block is executed after the return statement in the try or catch is executed, and the modified statement in the finally may or may not affect the return value that has been determined in the try or catch. If there is a return statement in Finally, the return statement in the try or catch is overwritten directly. Description: 1, the test case covered by this article is relatively full, but in the case of example 4 should be incorrect, according to understanding, coupled with experimental tests verified, the final output should be 204 instead of 85. This is what I want to add, in fact, when considering try-catch-finally and return execution order, if return is outside the block, and try block and catch block have no return statement, Then the try-catch-finally block in the execution of the value of the return variable is valid, specific analysis of the situation. 2, in the try or catch block there is a return statement, the value of return is calculated first, save it, assuming that res1, and then continue to run finally, the value of the above variable has been modified, assumed to be res2. When you debug with a breakpoint, you can see that the value of the variable after the return has been modified to Res2, but the final return value is Res1, which is important. As for the reference type, because it modifies the contents of the heap, the modification is valid, except that the modification of the previously computed reference value is invalid. The map in test Case 2 in the reproduced article is a reference value, because return has already determined the returned map, we assume that after the return of the map has a temporary variable saved as maptemp, both of them point to new out of the content of the piece. Later, in finally, the contents of the map's content were modified, and the value of map itself was modified to NULL, but this does not affect the value that was previously returned, since it was saved as maptemp, but the content pointed to is actually modified, Finally prints out finally. The approximate process is shown in 1. Figure 1
Execution order of return and finally in Java
