Je travaille sur le développement d'une application WebApplication avec le printemps 3 et hibernate 3.6. J'ai quelques questions à la -> Quand j'utilise Par exemple, lorsque j'ai eu une méthode qui charge, change et retourne, un objet et je l'appelle depuis une autre classe: dois-je entourer l'appel avec essayer / attraper? Peut-être que quelque chose ne va pas, aucun objet n'est retourné, la connexion de la base de données échoue. Je ne sais pas.
Jusqu'à présent, je pensais ou est-il suffisant de vérifier s'il y a un objet renvoyé (si / sinon), alors je n'ai pas besoin d'essayer / attraper?
Je suis nouveau et j'aimerais savoir comment autre structure leur code. Merci: -) @Transactional Annotation et la structure du code.
@TransAderal (gestion des transactions avec le ressort), dois-je entourer les méthodes @Transactional -Annoté avec essayer / attraper lors de les appeler?
@TransActional Cares pour toutes les exceptions possibles survenues et réalise chaque opération dans cette transaction lorsqu'une erreur se produit.
Mais si cela se produit, je dois informer l'utilisateur en quelque sorte. Lorsque j'appelle la méthode transactionnelle dans le bloc d'essai et qu'elle est renvoyée, le bloc de capture est activé?
Je peux dire que l'utilisateur "quelque chose s'est trompé". Sinon, l'utilisateur ne serait peut-être pas informé?
3 Réponses :
Exceptions de manutention au printemps est vraiment facile avec HandlerExceptionResSolvers et @ExceptionHandlers. J'ai tendance à utiliser @exceptionHandler exclusivement.
Vous pouvez utiliser un @ exceptionHandler pour gérer une exception spécifique au lieu de la manipuler vous-même dans un bloc d'essais. p>
si l'utilisateur voulait une ressource qui n'était pas trouvé et vous voulez envoyer un 404. p> s'il y avait un problème de serveur où vous voudriez envoyer un 500 P> @ExceptionHandler(SomeException.class)
public void handleException(SomeException exc, WebRequest request, HttpServletResponse response) {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "Sorry dude, my server broke");
}
Êtes-vous sérieux à propos de l'exemple de code? Les exceptions ne doivent jamais être avalées comme ça. De cette façon, le proxy n'a aucune chance de détecter l'exception et de faire rouler la transaction. J'espère que vous voulez dire quelque chose comme ceci: Catch (Someexception exc) {Jetez une nouvelle nouvelle ILGalStateException (exc); }
@San c'est juste pseudocode. J'espère qu'il n'aurait pas avaler une exception à moins d'avoir une bonne raison de le faire.
C'est pourquoi je demande, pas de descendre. Vous devriez faire des choses comme ça clair, il y a beaucoup de débutants autour de
Merci de répondre. Le second pseudocode était juste ce que j'ai mentionné im ma question. Je ne voulais pas attraper une exception dans une méthode transactionnelle, mais pour entourer l'appel d'une méthode transactionnelle annotée. Donc, la réponse n'est pas claire pour moi: je peux le faire de cette façon, mais je ne devrais pas? Comment puis-je informer un utilisateur si une transaction est renvoyée?
Vous pouvez utiliser une traduction d'exception comme mentionné dans la réponse de Sean pour générer une exception standard (au printemps de la saisie de DataAccessException ou autre) et utilisez une @ExceptionHandler pour attirer l'exception et informer l'utilisateur. J'ai mis à jour ma réponse pour montrer un exemple.
La fonction de clé utilisée par le ressort est traduction d'exception .
S'appuyer sur une traduction d'exception pour générer des exceptions votre couche client comprend et utilisez uniquement Essayez / attrapez uniquement, si possible.
Merci de me répondre. J'ai lu sur le lien (documentation de printemps) et j'ai trouvé ce qui suit:
"Cependant, le DAO jette une parfaite exception (qui n'est pas cochée, ne doit donc pas être déclarée ni prise), ce qui signifie que les appelants ne peuvent traiter que des exceptions généralement fatales - à moins qu'ils ne veuillent dépendre de la hiérarchie d'exception de Hibernate. Attraper des causes spécifiques telles qu'une défaillance de verrouillage optimiste n'est pas possible sans lier l'appelant à la stratégie de mise en œuvre. Ce compromis peut être acceptable pour les applications qui sont fortement basées sur l'hibernation et / ou n'ont pas besoin de traitement spécial d'exception. "
Mon DAO est basé sur une API de Hibernate de 3 plaine, donc si je comprends bien, mon DAO ne jette que des idées hibernées simples. Ils sont décochés et ne doivent pas être déclarés ou pris. Si quelque chose ne va pas, avec @TransActional, toute la opération est renvoyée.
Assurez-vous que tout fonctionne comme je m'attendais à ce que cela fonctionne, je dois attacher mon DAO encore plus proche de mon code d'application. Là, je peux vérifier par exemple si un objet est renvoyé ou non. (si NULL - sinon) Je pourrais aussi attraper l'exception, le loger et informer l'utilisateur que quelque chose s'est mal tourné et que sa transaction n'a pas fonctionné.
Donc, à ce stade, je pense toujours que - en fonction de la transaction: Si je peux travailler avec un résultat, tout va bien - sinon, je peux informer l'utilisateur.
Lorsque la transaction n'est pas spécifiée pour redonner un résultat, je peux utiliser Essayer / Catch pour attraper une hibernateException. Mais la transaction est-elle toujours retenue à l'époque? Je pensais que l'attraper une exception hibernateException évite de rouler de la transaction. Je ne sais toujours pas quoi faire. : - (
à côté de cela malheureusement, je ne comprends pas ce que la gestion des exceptions MVC (@ExceptionHandler) a à voir avec cela. Il y avait une table d'exceptions manipulées, mais je n'ai pas trouvé l'hibernateException. Ou pensez-vous que cela fonctionnera avec ceci: @ExceptionHandler (HibernateException.Class)? Aussi, vous avez dit que vous ne recommanderiez pas de gérer des exceptions de cette façon.