1.Conclusion
La gestion des transactions de Spring annule uniquement les exceptions d'exécution (java.lang.RuntimeException et ses sous-classes) par défaut.
Si une méthode lève une exception Exception ou Checked, la gestion des transactions Spring n'effectue pas de restauration par défaut.
Une introduction détaillée à la classification des exceptions :
1. Concepts de base <BR>Regardez le diagramme de structure des exceptions de Java
Throwable est la racine de toutes les exceptions, java.lang.Throwable
L'erreur est une erreur, java.lang.Error
L'exception est une exception, java.lang.Exception
2.Exception
Généralement divisées en exceptions Checked et exceptions Runtime. Toutes les instances de la classe RuntimeException et ses sous-classes sont appelées exceptions Runtime, et les exceptions qui n'entrent pas dans cette catégorie sont appelées CheckedExceptions.
① Exception vérifiée Seul le langage Java fournit des exceptions vérifiées. Java considère les exceptions vérifiées comme des exceptions qui peuvent être gérées, les programmes Java doivent donc explicitement gérer les exceptions vérifiées. Si le programme ne gère pas l'exception Checked, une erreur se produira lors de la compilation du programme et ne pourra pas être compilé. Cela reflète la philosophie de conception de Java : le code sans gestion parfaite des erreurs n'a aucune chance d'être exécuté. Il existe deux manières de gérer les exceptions vérifiées
(1) Si la méthode actuelle sait comment gérer l'exception, elle utilise le bloc try...catch pour gérer l'exception.
(2) Si la méthode actuelle ne sait pas comment la gérer, déclarez la levée de l'exception lors de la définition de la méthode.
Copiez le code comme suit :
paquet cn.xy.test ;
importer java.io.IOException ;
/**
* Méthode de test d'exception vérifiée
* @auteur xy
*
*/
classe publique CheckedExceptionMethods
{
//La classe d'exception totale inclut à la fois vérifiéException et RuntimeException, donc l'exception vérifiée doit être traitée
public void method1() lève une exception
{
System.out.println("Je suis la méthode de la classe générale qui lève des exceptions");
}
// Attrape et gère cette exception
public void testMethod1_01()
{
essayer
{
méthode1();
}
attraper (exception e)
{
e.printStackTrace();
}
}
// Passe l'exception
public void testMethod1_02() lève une exception
{
méthode1();
}
public void testMethod1_03() lève une exception
{
lancer une nouvelle exception ();
}
public void testMethod1_04()
{
essayer
{
lancer une nouvelle exception ();
}
attraper (exception e)
{
e.printStackTrace();
}
}
// checkException représente généralement IOException
public void method2() lance IOException
{
System.out.println("Je suis la méthode qui lève une exception IO");
}
testMethod2_01() public void
{
essayer
{
méthode2();
}
attraper (exception e)
{
e.printStackTrace();
}
}
public void testMethod2_02() lève une exception
{
méthode2();
}
}
Les exceptions vérifiées que nous connaissons mieux incluent
Java.lang.ClassNotFoundException
Java.lang.NoSuchMetodException
java.io.IOException
②Exception d'exécution
Au moment de l'exécution, si le diviseur est 0 ou si l'indice du tableau est hors limites, etc., cela se produit fréquemment et est difficile à gérer. L'affichage de déclarations ou de captures aura un grand impact sur la lisibilité et l'efficacité opérationnelle du programme. Ainsi, le système les détecte automatiquement et les transmet au gestionnaire d'exceptions par défaut. Bien entendu, vous pouvez également les capturer explicitement si vous avez des exigences de traitement.
Copiez le code comme suit :
paquet cn.xy.test ;
/**
* Méthode de test des exceptions d'exécution
* @auteur xy
*
*/
classe publique RuntimeExcetionMethods
{
public void method3() lance RuntimeException
{
System.out.println("Je suis une méthode qui lève des exceptions d'exécution");
}
public void testMethod3_01()
{
méthode3();
}
testMethod1_02() public void
{
lancer une nouvelle RuntimeException();
}
}
Les sous-classes de la classe RumtimeException que nous connaissons mieux incluent
Java.lang.ArithmeticException
Java.lang.ArrayStoreExcetpion
Java.lang.ClassCastException
Java.lang.IndexOutOfBoundsException
Java.lang.NullPointerException
3.Erreur Lorsqu'une erreur incontrôlable se produit dans un programme, l'approche habituelle consiste à en informer l'utilisateur et à mettre fin à l'exécution du programme. Contrairement aux exceptions, les objets de Error et ses sous-classes ne doivent pas être lancés.
Error est une sous-classe de throwable qui représente les erreurs de compilation et système et est utilisée pour indiquer des problèmes graves que des applications raisonnables ne devraient pas essayer de détecter.
Les erreurs sont générées et renvoyées par la machine virtuelle Java, notamment les échecs de liaison dynamique, les erreurs de machine virtuelle, etc. Le programme ne le traite pas.
2. Modifiez le mode par défaut <BR> Définissez noRollbackFor et RollbackFor dans l'annotation @Transaction pour spécifier s'il faut annuler certaines exceptions.
@Transaction(noRollbackFor=RuntimeException.class)
@Transaction(RollbackFor=Exception.class)
Cela modifie la méthode de traitement des transactions par défaut.
3. Lumières <BR>Cela nous oblige à faire en sorte que l'exception personnalisée hérite de RuntimeException lorsque nous personnalisons l'exception, de sorte que lorsqu'elle est levée, elle soit gérée avec précision par le traitement des transactions par défaut de Spring.
