java - SSM中异常怎么处理，包括io,net,业务异常？？？

Question

最近开发的项目中，dao,service,controller中的类都是throws Excepiton，但在方法中为什么还要catch后再抛，想知道SSM开发web应用详细的异常处理机制

Answer 1

Ce qui suit n'est que ma pratique personnelle et est uniquement à titre de référence.

Controller couche :
Sans l'intervention de AOP ou de Filter, je pense personnellement que toutes les exceptions générées dans les méthodes ici doivent être gérées

 ; Couche

DAO :
Les exceptions dans cette couche sont principalement des exceptions SQL, qui sont généralement renvoyées à la couche Service pour traitement

 ;

Service couche :
Si l'on considère que l'exception ne nécessite pas l'intervention de l'appelant, elle sera traitée au sein du Service, sinon elle sera renvoyée à l'appelant pour traitement (en fait, c'est un passage du blâme...);

Il n'y a qu'une seule situation dans laquelle je vais en attraper puis en lancer une autre Exception, qui consiste à attraper l'exception A puis à lancer l'exception B. Ceci est généralement combiné avec l'utilisation de AOP pour gérer les exceptions de manière uniforme, par exemple : catch Les exceptions A, B et C sont toutes gérées par le gestionnaire d'exceptions D de AOP.

Answer 2

Personnellement, je pense que le principe de la détection des exceptions est que vous ne devez détecter les exceptions que lorsque le code a des besoins de traitement métier pour les exceptions attendues. Par exemple, lorsqu'une erreur SQL se produit, vous devez annuler la transaction. Pour d'autres exceptions, il n'est fondamentalement pas nécessaire de détecter les exceptions. L'activité des couches peut gérer les exceptions de manière uniforme.

Answer 3

Quelques suggestions personnelles :

(1) Les exceptions vérifiées sont converties en RuntimeException. Le lancement de ceci est généralement considéré comme un bug
(2) Les exceptions personnalisées (exceptions métier) héritent de RuntimeException Lors de la conception d'exceptions personnalisées, le lancement d'exceptions doit être pris en compte. En quittant, le scénario anormal peut être rapidement reproduit grâce aux informations du journal.
(3) Concernant l'opportunité de lever une exception, d'une manière générale, si l'appelant a besoin de savoir qu'une exception métier peut se produire et peut la gérer, alors lancez-la. Si l'appelant ne peut pas gérer l'exception, elle sera interceptée. Bref, ne vous « rejetez pas la balle ».
(4) C'est fortement déconseillé catch Exception Ce type de code rendra difficile la localisation rapide du problème lorsqu'une exception se produit.

Answer 4

Il est recommandé que la couche Dao lance des exceptions directement vers le haut (généralement des exceptions d'exécution de base de données). La couche Service est exposée à d'autres applications, et de nombreuses informations commerciales devront être transmises à la couche

. appelants de couche supérieure, voici donc deux façons

1. Informez l'appelant des informations spécifiques sur l'exception métier/les informations sur l'exception système en lançant une exception métier (exceptions système, la couche supérieure peut ne pas y prêter attention)

2. ServiceResult garantit qu'aucune exception ne se produira et renvoie un Result à la couche supérieure. Les informations incluses dans

   sont : si l'appel réussit, et s'il échoue, il y aura. quelques informations commerciales

ServiceVous n'avez donc pas besoin d'intercepter les exceptions à tous les niveaux. Si vous souhaitez les gérer, gérez-les simplement dans

(qu'il s'agisse d'une seule application ou d'un futur service). dans le service dépend de l'équipe sélectionnée

Devrions-nous utiliser try{}catch{} pour contrôler le processus métier général, ou utiliser if() pour le contrôler<🎜>