javaWeb项目使用aop处理异常？

Question

1.dao层我是直接抛出异常，都是比较“底层”的异常，比如DataAccessException. 不捕获的原因是，假如service调用了多个dao方法，其中有一个发生了异常，如果该dao方法自己捕获了又没有重新抛出来。这时候，service事务没法回滚，因为它以为都执行正确了。
2.在service里， 调用的dao方法有可能抛出DataAccessException的话，那么service也不捕获。因为DataAccessException是runtime异常，无需强制try-catch,况且，如果你捕获了又没有抛出来，配置的事务没法感知到，因为默认只处理runtime异常，当然可以配置。
3.还可以这样，在service方法里，dao方法外面直接try-catch(Throwable e). 然后重新抛出自定义的业务相关的异常。比如TopicUpdateException.

问题：上面1,2,3我对dao层，service层的方法处理是否合理。2,3哪种更好些？为什么？

4.接上面，这个自定义的业务异常的粒度要控制到什么级别？能否举个例子
5.上面2，3 我都是用的aop统一处理异常。我看大部分人也推荐这么做。因为service层各个方法里catch里的逻辑大都相似。使用aop统一处理，好处是显而易见的。我想知道，有什么弊端吗？因为我发现公司项目几乎没有这么做的。都是直接try-catch，返回结果。要么就是上面2里提到的不捕获。出了异常反正可以记录在log里

请大家帮忙看看

Answer 1

Merci pour l'invitation ! Mais je dois déclarer que je ne suis pas un expert |_|

Question : Mon approche de la couche dao et de la couche de service dans les étapes 1, 2 et 3 ci-dessus est-elle raisonnable ? Lequel est le meilleur, 2 ou 3 ?

Tout d’abord, je suis d’accord avec votre analyse et votre compréhension des étapes 1, 2 et 3. Deuxièmement, je pense que le traitement de 3 est plus approprié, car la couche service n'est plus une pure interaction de données, mais contient une série d'opérations de logique métier en capturant Throwable puis en lançant des exceptions plus significatives ( qui peuvent décrire avec précision l'erreur), qu'elles soient enregistrées dans les journaux ou dans le traitement des transactions, sont plus adaptées à une éventuelle correction/dépannage ultérieur de l'erreur

4. Dans la continuité de ce qui précède, jusqu'à quel niveau la granularité de cette exception métier personnalisée doit-elle être contrôlée ? Pouvez-vous me donner un exemple

La granularité dépend des exigences. Par exemple, si vous souhaitez uniquement effectuer une restauration, alors tant que vous pouvez localiser ce qui service ne va pas, cela vous suffit. Mais si vous souhaitez quand même poursuivre le dépannage root cause, ne serait-il pas préférable d'inclure plus de description de l'erreur source dans le message d'exception ?

5. Dans les points 2 et 3 ci-dessus, j'utilise aop pour gérer les exceptions de manière uniforme. Je pense que la plupart des gens le recommandent. Parce que la logique de capture dans chaque méthode de la couche de service est pour l’essentiel similaire. Les avantages de l'utilisation d'aop pour un traitement unifié sont évidents. Je veux savoir, y a-t-il des inconvénients ? Parce que j’ai constaté que presque aucun projet d’entreprise ne fait cela. Ce sont tous des résultats d'essai-catch et de retour directs. Ou alors c'est la non-capture évoquée en 2 ci-dessus. Si une exception se produit, elle peut être enregistrée dans le journal

Tout d'abord, parlons des raisons pour lesquelles votre entreprise n'a pas fait cela. Cela peut être dû à des raisons historiques. Les personnes qui ont construit le cadre auparavant n'en connaissaient pas suffisamment aop, ou y ont apporté leurs préférences personnelles. travailler et ont choisi d'aller directement partout try catch(cette méthode Simple et grossière, la plus facile à maîtriser), aop est considérée comme un paradigme de conception Qu'ils soient architectes ou programmeurs, ils doivent encore apprendre à la maîtriser et à l'utiliser librement (cela. peut être un inconvénient). Si la raison vous intéresse, il est préférable de discuter en privé avec quelques collègues seniors, vous pourrez peut-être obtenir d'autres informations privilégiées ^^

Concernant "toute exception peut de toute façon être enregistrée dans le journal", l'idée n'est pas fausse, mais les personnes qui ont effectivement traité des messages d'erreur dans des journaux massifs comprendront. Il est évident que cela peut être traité de manière uniforme, mais cela n’est pas fait. Ceci est considéré comme un défaut ou une erreur de conception. Pas la solution la plus efficace au problème

Je suis un profane, veuillez cliquer légèrement ^^

Answer 2

Utilisez Spring AOP pour gérer uniformément les exceptions. Bien sûr, la troisième méthode est meilleure. Utilisez Spring AOP pour intercepter les exceptions levées par la couche de service, enregistrer tous les journaux d'exceptions non gérés et convertir toutes les exceptions non gérées en exceptions système personnalisées unifiées afin que la couche contrôleur ou la couche Rpc puisse gérer ces exceptions personnalisées. Les informations sont renvoyées au front-end. et affiché du côté du navigateur.
N'oubliez pas que la véritable fonction de l'utilisation de Spring AOP pour intercepter les exceptions est de découpler la logique de traitement des exceptions de la logique de traitement normale. Alors, à votre avis, à quel niveau la granularité des exceptions est-elle contrôlée ? Ceci est basé sur votre logique métier. Par exemple, l'opération d'ajout, de suppression, de modification et de vérification de la base de données a échoué ? Échec de l'appel de l'interface externe ? Autres informations anormales, etc.
Les méthodes de votre entreprise sont irrégulières et inappropriées. Lors du traitement des journaux, vous devez inclure du code de traitement dans chaque bloc try-catch. Parfois, le code de gestion des exceptions est supérieur au code d'exécution normal, polluant le code d'exécution normal. Le code de gestion des exceptions est dispersé et est très difficile à modifier. Certaines exceptions ne peuvent pas être traitées et modifiées de manière uniforme.
Si la dénomination de la méthode métier dans Service n'est pas nommée selon les règles prédéfinies, AOP ne peut pas l'intercepter. En d’autres termes, le contrôle des transactions ne peut pas être chargé. Ces conventions de dénomination doivent être spécifiées dans le fichier de configuration.

Answer 3

Nous traitons tous les exceptions AOP dans la couche contrôleur
Les exceptions sont divisées en exceptions non-ajax et exceptions ajax. Parce que nous utilisons jquery, le front-end et le back-end ne sont pas complètement séparés. est directement rendu par le back-end

.

1. exception ajax : Contenir X-Requested-With dans l'en-tête pour déterminer

2. Exceptions non-ajax :
   autres que les exceptions ajax. La façon dont votre réception affiche les erreurs aux clients est définitivement différente, alors gérez-les séparément dans Interceptor (filter) (aop)

Dans chaque méthode de la classe de service, il n'est pas dit que la méthode entière est enveloppée par try catch. C'est trop. Les exceptions sont divisées en éléments que vous ne pouvez pas contrôler, comme les exceptions de base de données, les pointeurs nuls, etc. Ceux-ci n'ont pas besoin d'être interceptés.En service Il est lancé en fonction d'une activité anormale dans l'entreprise. Par exemple, si le nom d'utilisateur est répété, je lancerai une BizException ("Nom d'utilisateur dupliqué"), où BizException hérite de RuntimeException<.>

L'aop mentionné par lz est utilisé pour gérer les exceptions. Je ne sais pas si vous êtes dans la couche service ou dans la couche contrôleur. Évidemment, d'après mon analyse ci-dessus, cela devrait être fait dans la couche contrôleur

.

Si ce n'est pas la meilleure réponse, ce serait déraisonnable

Answer 4

Utilisez-vous Spring MVC ? Spring MVC gère les exceptions globales. Vous pouvez le rechercher. Je ne peux pas exprimer facilement les détails sur mon téléphone mobile.