Gestion des exceptions
1. [Obligatoire] N'interceptez pas les classes d'exception d'exécution définies dans la bibliothèque de classes Java qui héritent de RuntimeException, telles que : IndexOutOfBoundsException / NullPointerException. De telles exceptions sont évitées par les programmeurs pour pré-vérifier pour garantir la robustesse du programme.
Exemple positif : if(obj != null) {...}
Contre-exemple : try { obj.method() } catch(NullPointerException e){...}
2. Obligatoire 】Les exceptions ne doivent pas être utilisées pour le contrôle de processus ou le contrôle conditionnel, car l'efficacité de traitement des exceptions est inférieure à celle des branches conditionnelles.
3. [Obligatoire] Essayez - capturez une grande section de code, c'est irresponsable. Lors de la capture, veuillez faire la distinction entre le code stable et le code non stable. Le code stable fait référence au code qui ne se trompera pas quoi qu'il arrive. Pour les captures dans du code instable, essayez de distinguer autant que possible les types d'exceptions, puis gérez les exceptions correspondantes. 4. [Obligatoire] Attrapez une exception afin de la gérer. Ne l'attrapez pas et ne la supprimez pas sans rien traiter, veuillez lancer l'exception à son appelant. L'utilisateur professionnel le plus externe doit gérer les exceptions et les convertir en
contenu que les utilisateurs peuvent comprendre. 5. [Obligatoire] Mettez un bloc try dans le code de transaction. Après avoir détecté l'exception, si vous devez annuler la transaction, vous devez faire attention à annuler manuellement la transaction.
6. [Obligatoire] Le bloc final doit fermer l'objet ressource et l'objet flux, et essayer-catch s'il y a une exception.
Remarque :Si JDK 7, vous pouvez utiliser la méthode try - with - resources.
7. [Obligatoire] Return ne peut pas être utilisé dans le bloc final. Après le retour dans le bloc final, la méthode termine l'exécution et l'instruction return dans le bloc try ne sera plus exécutée.
8. [Obligatoire] L'exception interceptée et l'exception levée doivent correspondre exactement, ou l'exception capturée est la classe parent de l'exception levée.Remarque :
Si l'adversaire est censé lancer une balle d'hortensia mais reçoit en réalité un lancer du poids, une situation inattendue se produira. 9. [Recommandé] La valeur de retour de la méthode peut être nulle. Il n'est pas obligatoire de renvoyer une collection vide ou un objet vide. Vous devez ajouter suffisamment de commentaires pour expliquer dans quelles circonstances une valeur nulle sera renvoyée. L'appelant doit effectuer un jugement nul pour éviter les problèmes NPE.Remarque :
Ce protocole indique clairement que la prévention des NPE relève de la responsabilité de l'appelant. Même si la méthode appelée renvoie une collection ou un objet vide, l'appelant ne pourra pas s'asseoir et se détendre et doit considérer la situation dans laquelle null est renvoyé dans des scénarios tels que l'échec d'un appel à distance et les exceptions d'exécution.
10. [Recommandation] La prévention des NPE est la formation de base des programmeurs. Faites attention aux scénarios dans lesquels les NPE se produisent :.
1) Le type de retour est un type de données compressé, qui peut être nul Lorsque vous renvoyez une valeur int, veillez à vérifier la valeur null.
Contre-exemple : public int f() { return Integer object} ; S'il est nul, il déballera automatiquement et lancera NPE.
2) Le résultat de la requête de la base de données peut être nul.
3) Même si les éléments de la collection sont isNotEmpty, les éléments de données récupérés peuvent être nuls.
4) Un jugement NPE est toujours requis pour les objets renvoyés par des appels à distance.
5) Pour les données obtenues en Session, il est recommandé de vérifier NPE pour éviter les pointeurs nuls.
6) Appels en cascade obj . getA() . getB() .
11. [Recommandation] Qu'il s'agisse d'utiliser « lancer une exception » ou « renvoyer un code d'erreur » dans le code, le « code d'erreur » doit être utilisé pour les interfaces ouvertes http/api en dehors de l'entreprise et le lancement d'exceptions est recommandé au sein de l'application ; inter-applications La priorité est donnée à l'utilisation de la méthode Result pour les appels RPC, et isSuccess, le « code d'erreur » et les « brèves informations sur l'erreur » sont installés. Explication :
Raisons d'utilisation de la méthode Result pour le retour de la méthode RPC :1) En utilisant la méthode de retour d'exception, une erreur d'exécution se produira si l'appelant ne l'attrape pas.
2) Si vous n'ajoutez pas d'informations sur la pile, juste de nouvelles exceptions personnalisées et ajoutez votre propre compréhension du message d'erreur, cela ne sera pas d'une grande aide à la fin de l'appelpour résoudre le problème. Si des informations sur la pile sont ajoutées, en cas d'erreurs d'appel fréquentes, la perte de performances de sérialisation et de transmission des données constitue également un problème.
12. [Recommandation] Faites la distinction entre les exceptions non cochées/cochées lors de la définition et évitez d'utiliser RuntimeException pour les lancer directement Il n'est pas autorisé de lancer des exceptions ou des exceptions personnalisées ayant une signification commerciale. Exceptions personnalisées recommandées qui ont été définies dans l'industrie, telles que : DAOException / ServiceException, etc.
13. [Référence] Évitez les codes en double (Ne vous répétez pas), c'est-à-dire le principe DRY.Remarque : Copier et coller du code à volonté entraînera inévitablement une duplication du code. Lorsque vous devrez le modifier à l'avenir, vous devrez modifier toutes les copies, ce qui est facile à manquer. Extrayez des méthodes communes, des classes publiques abstraites ou même des modules partagés si nécessaire.
Exemple positif :Il existe plusieurs méthodes publiques dans une classe, et elles doivent toutes effectuer plusieurs lignes des mêmes opérations de vérification de paramètres. À ce stade, veuillez extraire : private boolean checkParam(DTO dto){. ..}
