1. Conclusion
Spring's transaction management only rolls back runtime exceptions (java.lang.RuntimeException and its subclasses) by default.
If a method throws an Exception or Checked exception, Spring transaction management does not perform rollback by default.
A detailed introduction to the classification of exceptions:
1. Basic concepts <BR>Look at the exception structure diagram of java
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.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.
① Checked exception Only the Java language provides Checked exceptions. Java considers Checked exceptions to be exceptions that can be handled, so Java programs must explicitly handle Checked exceptions. If the program does not handle the Checked exception, an error will occur when the program is compiled and cannot be compiled. This reflects Java's design philosophy: code without perfect error handling has no chance of being executed. There are two ways to handle Checked exceptions
(1) If the current method knows how to handle the exception, it uses try...catch block to handle the exception.
(2) If the current method does not know how to handle it, then declare to throw the exception when defining the method.
Copy the code code as follows:
package cn.xy.test;
import java.io.IOException;
/**
* Checked exception testing method
* @author xy
*
*/
public class CheckedExceptionMethods
{
//The total exception class includes both checkedException and RuntimeException, so the checkedException must be processed
public void method1() throws Exception
{
System.out.println("I am the method of the general class that throws exceptions");
}
//Catch and handle this exception
public void testMethod1_01()
{
try
{
method1();
}
catch (Exception e)
{
e.printStackTrace();
}
}
// Pass 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 am the method that throws IO exception");
}
public void testMethod2_01()
{
try
{
method2();
}
catch (Exception e)
{
e.printStackTrace();
}
}
public void testMethod2_02() throws Exception
{
method2();
}
}
The Checked exceptions we are more familiar with include
Java.lang.ClassNotFoundException
Java.lang.NoSuchMetodException
java.io.IOException
②RuntimeException
In runtime, if the divisor is 0 or the array subscript is out of bounds, etc., they occur frequently and are troublesome to deal with. Displaying declarations or captures will have a great impact on the readability and operating efficiency of the program. So the system automatically detects them and hands them over to the default exception handler. Of course, you can also capture them explicitly if you have processing requirements.
Copy the code code as follows:
package cn.xy.test;
/**
* Runtime exception testing method
* @author xy
*
*/
public class RuntimeExcetionMethods
{
public void method3() throws RuntimeException
{
System.out.println("I am a method that throws runtime exceptions");
}
public void testMethod3_01()
{
method3();
}
public void testMethod1_02()
{
throw new RuntimeException();
}
}
The subclasses of the RumtimeException class that we are more familiar with include
Java.lang.ArithmeticException
Java.lang.ArrayStoreExcetpion
Java.lang.ClassCastException
Java.lang.IndexOutOfBoundsException
Java.lang.NullPointerException
3.Error When an uncontrollable error occurs in a program, the usual approach is to notify the user and terminate the execution of the program. Unlike exceptions, objects of Error and its subclasses should not be thrown.
Error is a subclass of throwable that represents compile-time and system errors and is used to indicate serious problems that reasonable applications should not try to catch.
Errors are generated and thrown by the Java virtual machine, including dynamic link failures, virtual machine errors, etc. The program does not process it.
2. Change the default mode <BR> Define noRollbackFor and RollbackFor in the @Transaction annotation to specify whether to rollback certain exceptions.
@Transaction(noRollbackFor=RuntimeException.class)
@Transaction(RollbackFor=Exception.class)
This changes the default transaction processing method.
3. Enlightenment <BR>This requires us to make the custom exception inherit from RuntimeException when we customize the exception, so that when it is thrown, it will be accurately handled by Spring's default transaction processing.
