Dans les projets réels, la couche de logique métier et la couche de service génèrent uniquement des exceptions mais ne les gèrent pas.
Détecter les exceptions et les gérer dans la couche de présentation (journalisation ou autre) ?
Il semble que cela ne s'applique pas si les frontaux et les backends sont séparés. La capture des exceptions doit être capturée à l'endroit où le service ou la logique est appelé ? Est-ce vrai ?
À quoi ressemble la gestion des exceptions dans vos projets actuels ? S'il vous plaît, donnez-moi quelques conseils ! ! ! ! !
La couche de service effectuera la journalisation. De manière générale, les exceptions levées sont capturées par la couche de présentation, mais elles seront également capturées et enregistrées d'abord dans la couche de service, puis levées
Tout d'abord, nous devons clarifier un concept : les exceptions sont lancées vers les programmeurs, pas vers les utilisateurs.
Après avoir clarifié ce concept, il est facile de comprendre pourquoi les exceptions doivent être gérées dans la couche de présentation - parce que la couche de présentation est la dernière barrière entre les programmeurs et les utilisateurs, les exceptions doivent être joliment emballées et envoyées au client, c'est-à-dire le ainsi -appelée expérience utilisateur.
Cependant, la couche de présentation n'est certainement pas le seul endroit qui doit gérer les exceptions. Les endroits que vous avez mentionnés, y compris la couche inférieure, le serveur... doivent tous gérer les exceptions de manière appropriée.
Par exemple, l'interface fournie par le serveur prend généralement en compte l'expérience de l'appelant, elle ne lancera donc pas d'exception directement, mais doit être encapsulée dans une certaine mesure, et en même temps, les informations sur l'exception sont enregistrées sur le serveur pour la vérification des erreurs.
Bien entendu, afin de simplifier et d'unifier le processus de traitement, le traitement des exceptions est généralement concentré à certains niveaux, y compris la couche de présentation.