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 ^^

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.

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<.>

.

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.