Spring transaction management only rolls back runtime exceptions that occur

  • 2020-04-01 01:07:47
  • OfStack

A, the conclusion
Spring's transaction management by default only to a runtime exception (Java. Lang. RuntimeException and its subclasses) are rolled back.
If a method throws an Exception or Checked Exception, Spring transaction management does not roll back by default.
The classification of exceptions is described in detail:
1. Basic concepts
Look at the Java exception structure diagram
(link: #)  
Throwable is the root of all exceptions, java.lang.Throwable
Error is an Error, java.lang.Error
Exception is an Exception, java.lang.exception
2, the Exception
Generally divided into Checked exceptions and Runtime exceptions, all instances of the RuntimeException class and its subclasses are called Runtime exceptions, and exceptions that do not fall into this category are called checkedexceptions.
1) Checked exceptions
Only the Java language provides Checked exceptions, and Java considers Checked exceptions to be exceptions that can be handled, so the Java program must show that it handles Checked exceptions. If a program does not handle Checked exceptions, an error occurs at compile time that prevents the program from compiling. This is part of the design philosophy of Java: code without proper error handling has no chance of being executed. There are two methods for handling Checked exceptions
(1) if the current method knows how to handle the exception, try... The catch block handles the exception.
(2) the current method does not know how to handle, then declare the exception in the definition of the method.

 
package cn.xy.test; 
import java.io.IOException; 
 
public class CheckedExceptionMethods 
{ 
//The total exception class has both checkedException and RuntimeException, so the checkedException in it must be handled
public void method1() throws Exception 
{ 
System.out.println(" I'm the method that throws the total class of exceptions "); 
} 
//Catch and handle this exception
public void testMethod1_01() 
{ 
try 
{ 
method1(); 
} 
catch (Exception e) 
{ 
e.printStackTrace(); 
} 
} 
//Pass on the exception
public void testMethod1_02() throws Exception 
{ 
method1(); 
} 
public void testMethod1_03() throws Exception 
{ 
throw new Exception(); 
} 
public void testMethod1_04() 
{ 
try 
{ 
throw new Exception(); 
} 
catch (Exception e) 
{ 
e.printStackTrace(); 
} 
} 
//CheckedException typically represents IOException
public void method2() throws IOException 
{ 
System.out.println(" I was thrown IO Method of exception "); 
} 
public void testMethod2_01() 
{ 
try 
{ 
method2(); 
} 
catch (Exception e) 
{ 
e.printStackTrace(); 
} 
} 
public void testMethod2_02() throws Exception 
{ 
method2(); 
} 
} 

We are familiar with Checked exceptions
Java. Lang. ClassNotFoundException
Java. Lang. NoSuchMetodException
Java. IO. IOException
(2) RuntimeException
Runtime such as divisor is 0 and array index overbounds, it produces frequent, processing trouble, if the display declaration or capture will have a great impact on the readability and running efficiency of the program. So the system detects them automatically and hands them over to the default exception handler. Of course you can also display capture them if you have processing requirements.
 
package cn.xy.test; 
 
public class RuntimeExcetionMethods 
{ 
public void method3() throws RuntimeException 
{ 
System.out.println(" I'm the method that throws the runtime exception "); 
} 
public void testMethod3_01() 
{ 
method3(); 
} 
public void testMethod1_02() 
{ 
throw new RuntimeException(); 
} 
} 

The more familiar subclass of the RumtimeException class is
Java. Lang. ArithmeticException
Java. Lang. ArrayStoreExcetpion
Java. Lang. ClassCastException
Java. Lang. IndexOutOfBoundsException
Java. Lang. NullPointerException
3, the Error
When an uncontrollable error occurs in a program, it is common practice to notify the user and abort the execution of the program. Unlike exceptions, objects of an Error and its subclasses should not be thrown.
Error is a subclass of throwable, representing compile time and system errors, and is used to indicate that a reasonable application should not attempt to catch a serious problem.
Errors are generated and thrown by the Java virtual machine, including dynamic link failures, virtual machine errors, and so on. The program doesn't do anything about it.
Second, change the default mode
NoRollbackFor and RollbackFor are defined in the @transaction annotation to specify whether an exception is rolled back.
@ Transaction (noRollbackFor = RuntimeException class)
@ Transaction (RollbackFor = Exception. Class)
This changes the default transaction handling.
Third, revelation
This requires that when we customize the exception, we let the custom exception inherit from the RuntimeException so that when thrown it will be handled exactly by Spring's default transaction.


Related articles: