I. Conclusion
Spring's transaction management defaults to rollback only for a Run-time exception (Java.lang.RuntimeException and its subclasses).
If a method throws a exception or checked exception, spring transaction management defaults to no rollback.
About the classification of the exception of the detailed description:
1. Basic Concepts
Look at the exception structure diagram of Java
Throwable is the root of all anomalies, java.lang.Throwable
Error is wrong, java.lang.Error
Exception is abnormal, java.lang.Exception
2, Exception
Generally divided into checked anomalies and runtime exceptions, all instances of runtimeexception classes and their subclasses are called Runtime exceptions, and exceptions that do not fall into the category are called Checkedexception.
①checked exception
Only the Java language provides checked exceptions, and Java thinks checked exceptions are exceptions that can be handled, so Java programs must display the handling of checked exceptions. If the program does not handle the checked exception, the program will compile with an error that cannot be compiled. This embodies the philosophy of Java design: code without perfect error handling has no chance of being executed at all. There are two kinds of methods for checked exception handling
(1) The current method knows how to handle the exception, and the Try...catch block is used to handle the exception.
(2) The current method does not know what to do, the exception is thrown when the method is defined to be declared.
Copy Code code as follows:
Package cn.xy.test;
Import java.io.IOException;
/**
* Checked anomaly test method
* @author XY
*
*/
public class Checkedexceptionmethods
{
Total anomaly classes, both checkedexception and runtimeexception, so the checkedexception must be handled
public void Method1 () throws Exception
{
System.out.println ("I am the method of throwing out the general class of exceptions");
}
Capturing and handling this exception
public void testmethod1_01 ()
{
Try
{
Method1 ();
}
catch (Exception e)
{
E.printstacktrace ();
}
}
Pass the anomaly down.
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 Typical Representative IOException
public void Method2 () throws IOException
{
System.out.println ("I am a method of throwing IO exceptions");
}
public void testmethod2_01 ()
{
Try
{
Method2 ();
}
catch (Exception e)
{
E.printstacktrace ();
}
}
public void testmethod2_02 () throws Exception
{
Method2 ();
}
}
We are more familiar with the checked anomaly has
Java.lang.ClassNotFoundException
Java.lang.NoSuchMetodException
Java.io.IOException
②runtimeexception
Runtime such as the divisor is 0 and a set of subscript out of bounds, and so on, it produces frequent, handling trouble, if the display of the declaration or capture will be the readability of the program and operational efficiency. So the system automatically detects them and hands them to the default exception handler. Of course, if you have any processing requirements, you can also display the capture.
Copy Code code as follows:
Package cn.xy.test;
/**
* Runtime anomaly test method
* @author XY
*
*/
public class Runtimeexcetionmethods
{
public void Method3 () throws RuntimeException
{
System.out.println ("I am a method of throwing run-time exceptions");
}
public void testmethod3_01 ()
{
Method3 ();
}
public void testmethod1_02 ()
{
throw new RuntimeException ();
}
}
The subclasses of the Rumtimeexception class that we are familiar with are
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, it is common practice to notify the user and abort execution of the program. Unlike an exception, an object that is an error and its subclasses should not be thrown.
Error is a subclass of Throwable that represents compile time and system errors that indicate a serious problem that reasonable applications should not attempt to capture.
The error is generated and thrown by the Java virtual machine, including dynamic link failures, virtual machine errors, and so on. The program does not handle it.
Second, change the default mode
Define Norollbackfor and Rollbackfor in the @transaction note to specify whether an exception is rolled back.
@Transaction (Norollbackfor=runtimeexception.class)
@Transaction (Rollbackfor=exception.class)
This changes the default transaction mode.
iii. Revelation
This requires us to allow custom exceptions to inherit from RuntimeException when we customize the exception, so that it is handled precisely by the spring default transaction processing.
