Version imprimable
bonjour,
je souhaite savoir si c'est une bonne pratique du point de vue de la gestion des erreurs/exceptions dans une architecture MVC
les try catch se trouvent uniquement dans le code des controleurs,
pas de gestion des erreurs dans les codes des modèles.
Est-ce une bonne pratique?
merci d'avance
Bonjour,
Le Contrôleur étant l'objet ultime avant la Vue qui peut légitimement contenir de la logique non-"pur UI", c'est effectivement une bonne idée d'y gérer les exceptions qui seraient passées au travers des mailles des couches précédentes. Ca ne veut pas dire que chaque méthode de Contrôleur doit contenir un try/catch - la plupart des frameworks MVC fournissent des mécanismes centralisés pour gérer les exceptions uniformément sur toutes les actions des Contrôleurs. Ex : pour toutes les business exceptions, je reste sur la même page en affichant le message d'erreur dans un encadré. Pour toutes les exceptions techniques, je renvoie vers une page d'erreur technique, etc.
Néanmoins, un Contrôleur particulier pourra exceptionnellement avoir besoin de faire un try/catch quand il s'attend à un type d'exception spécifique et veut la gérer aux petits oignons, mais cela reste rare.
C'est moins vrai, attraper les exceptions dans les Contrôleurs ne nous affranchit pas de la nécessité de s'en occuper dans les autres couches. La notion de Model en MVC est tellement vague qu'elle peut recouper à peu près n'importe quelle réalité, mais voici des exemples de gestions des exceptions qui pourraient être menées dans le "Model" :Citation:
pas de gestion des erreurs dans les codes des modèles
- Attraper une exception de plus bas niveau et décider l'impact que cela doit avoir sur une transaction métier en cours (rollback, continuation...). Ex : boutique en ligne, le serveur de mail me renvoie une exception lorsque j'essaie d'envoyer le mail de confirmation de commande à mon client. Cela doit-il annuler la transaction ?
- Lever une exception typée Business quand une chose interdite par une règle métier se produit.
- Lever une exception technique fine quand un cas problématique techniquement se présente (paramètre null, cast illégitime...). Ca peut paraître de la programmation défensive mais c'est peut-être plus parlant que par exemple une NullReferenceException qui se produira immanquablement plus tard dans l'exécution.
- etc.
un bon article sur le sujet : http://codebetter.com/karlseguin/200...cs-exceptions/