1. Fazit
Das Transaktionsmanagement von Spring setzt standardmäßig nur Laufzeitausnahmen (java.lang.RuntimeException und seine Unterklassen) zurück.
Wenn eine Methode eine Ausnahme oder eine geprüfte Ausnahme auslöst, führt die Spring-Transaktionsverwaltung standardmäßig kein Rollback durch.
Eine ausführliche Einführung in die Klassifizierung von Ausnahmen:
1. Grundkonzepte <BR>Sehen Sie sich das Ausnahmestrukturdiagramm von Java an
Throwable ist die Wurzel aller Ausnahmen, java.lang.Throwable
Fehler ist ein Fehler, java.lang.Error
Ausnahme ist eine Ausnahme, java.lang.Exception
2. Ausnahme
Im Allgemeinen werden alle Instanzen der RuntimeException-Klasse und ihrer Unterklassen in Checked-Ausnahmen und Runtime-Ausnahmen unterteilt. Ausnahmen, die nicht in diese Kategorie fallen, werden als CheckedExceptions bezeichnet.
① Geprüfte Ausnahme Nur die Java-Sprache bietet geprüfte Ausnahmen. Java betrachtet geprüfte Ausnahmen als Ausnahmen, die behandelt werden können, daher müssen Java-Programme geprüfte Ausnahmen explizit behandeln. Wenn das Programm die Checked-Ausnahme nicht behandelt, tritt beim Kompilieren des Programms ein Fehler auf, der nicht kompiliert werden kann. Dies spiegelt die Designphilosophie von Java wider: Code ohne perfekte Fehlerbehandlung hat keine Chance, ausgeführt zu werden. Es gibt zwei Möglichkeiten, geprüfte Ausnahmen zu behandeln
(1) Wenn die aktuelle Methode weiß, wie die Ausnahme zu behandeln ist, verwendet sie den Block try...catch, um die Ausnahme zu behandeln.
(2) Wenn die aktuelle Methode nicht weiß, wie sie damit umgehen soll, deklarieren Sie beim Definieren der Methode, dass sie die Ausnahme auslöst.
Kopieren Sie den Codecode wie folgt:
Paket cn.xy.test;
import java.io.IOException;
/**
* Überprüfte Ausnahmetestmethode
* @Autor xy
*
*/
öffentliche Klasse CheckedExceptionMethods
{
// Die Gesamtausnahmeklasse enthält sowohl „checkedException“ als auch „RuntimeException“, sodass die „checkedException“ verarbeitet werden muss
public void method1() löst eine Ausnahme aus
{
System.out.println("Ich bin die Methode der allgemeinen Klasse, die Ausnahmen auslöst");
}
//Diese Ausnahme abfangen und behandeln
public void testMethod1_01()
{
versuchen
{
method1();
}
Catch (Ausnahme e)
{
e.printStackTrace();
}
}
// Die Ausnahme übergeben
public void testMethod1_02() löst eine Ausnahme aus
{
method1();
}
public void testMethod1_03() löst eine Ausnahme aus
{
throw new Exception();
}
public void testMethod1_04()
{
versuchen
{
throw new Exception();
}
Catch (Ausnahme e)
{
e.printStackTrace();
}
}
// geprüfte Ausnahme stellt normalerweise eine IOException dar
public void method2() löst eine IOException aus
{
System.out.println("Ich bin die Methode, die eine E/A-Ausnahme auslöst");
}
public void testMethod2_01()
{
versuchen
{
method2();
}
Catch (Ausnahme e)
{
e.printStackTrace();
}
}
public void testMethod2_02() löst eine Ausnahme aus
{
method2();
}
}
Zu den geprüften Ausnahmen, mit denen wir besser vertraut sind, gehören:
Java.lang.ClassNotFoundException
Java.lang.NoSuchMetodException
java.io.IOException
②RuntimeException
Wenn der Divisor zur Laufzeit 0 ist oder der Array-Index außerhalb der Grenzen liegt usw., treten sie häufig auf und sind problematisch. Die Anzeige von Deklarationen oder Erfassungen hat große Auswirkungen auf die Lesbarkeit und Betriebseffizienz des Programms. Das System erkennt sie also automatisch und übergibt sie an den Standard-Ausnahmebehandler. Selbstverständlich können Sie diese bei Bearbeitungsbedarf auch explizit erfassen.
Kopieren Sie den Codecode wie folgt:
Paket cn.xy.test;
/**
* Methode zum Testen von Laufzeitausnahmen
* @Autor xy
*
*/
öffentliche Klasse RuntimeExcetionMethods
{
public void method3() löst eine RuntimeException aus
{
System.out.println("Ich bin eine Methode, die Laufzeitausnahmen auslöst");
}
public void testMethod3_01()
{
method3();
}
public void testMethod1_02()
{
throw new RuntimeException();
}
}
Zu den Unterklassen der RumtimeException-Klasse, mit denen wir besser vertraut sind, gehören:
Java.lang.ArithmeticException
Java.lang.ArrayStoreExcetpion
Java.lang.ClassCastException
Java.lang.IndexOutOfBoundsException
Java.lang.NullPointerException
3.Fehler Wenn in einem Programm ein unkontrollierbarer Fehler auftritt, besteht die übliche Vorgehensweise darin, den Benutzer zu benachrichtigen und die Ausführung des Programms abzubrechen. Im Gegensatz zu Ausnahmen sollten Objekte von Error und seinen Unterklassen nicht ausgelöst werden.
Error ist eine Unterklasse von throwable, die Kompilierzeit- und Systemfehler darstellt und verwendet wird, um auf schwerwiegende Probleme hinzuweisen, die vernünftige Anwendungen nicht abfangen sollten.
Fehler werden von der Java Virtual Machine generiert und ausgelöst, einschließlich dynamischer Verbindungsfehler, Fehler der virtuellen Maschine usw. Das Programm verarbeitet es nicht.
2. Ändern Sie den Standardmodus <BR>. Definieren Sie noRollbackFor und RollbackFor in der @Transaction-Annotation, um anzugeben, ob bestimmte Ausnahmen rückgängig gemacht werden sollen.
@Transaction(noRollbackFor=RuntimeException.class)
@Transaction(RollbackFor=Exception.class)
Dadurch wird die standardmäßige Transaktionsverarbeitungsmethode geändert.
3. Aufklärung <BR>Dazu müssen wir dafür sorgen, dass die benutzerdefinierte Ausnahme von RuntimeException erbt, wenn wir die Ausnahme anpassen, damit sie beim Auslösen von der Standardtransaktionsverarbeitung von Spring genau verarbeitet wird.
