Dans mon application ASP.NET MVC, je ne veux pas signaler à tous les messages d'exception à l'utilisateur. Mais il existe certains types d'exceptions que j'aimerais signaler à l'utilisateur. J'ai donc créé un filtre d'action pour décider si c'est ce type d'exception particulier, puis affichez le message de l'exception, sinon affichez un message générique. J'ai donc créé une exception personnalisée appelée clientException.
Mon filtre ressemble à ceci: p>
if (filterContext.Exception is ClientException)
message = filterContext.Exception.Message.Replace("\r", " ").Replace("\n", " ");
else
message = "An error occured while attemting to perform the last action. Sorry for the inconvenience.";
filterContext.HttpContext.Response.Status = "500 " + message;
5 Réponses :
Si votre approche fonctionne pour vous, tout va bien. Et êtes-vous surpris qu'un blog Microsoft recommande d'utiliser leur classe d'exception? ;)
Il existe certaines fonctionnalités de la bibliothèque .NET et des trucs OSR de 3ème partie qui ne fonctionnent cependant pas avec des exceptions .NET.
Pour obtenir le meilleur des deux mondes, vous pouvez toujours étendre l'objet d'exception .NET dans votre propre.
J'utiliserais différentes valeurs de seuil en fonction du type d'exception, et ces valeurs de seuil seraient associées aux messages d'exception.
basé sur la logique de valeur de seuil particulière, vous pouvez choisir de décider de montrer ou non une exception.
Votre approche est bonne imo mais il y a des alternatives. (Nous sommes des développeurs de logiciels, il y a donc toujours des alternatives.)
Vous pouvez exploiter le Données d'exception Dictionnaire à Stockez un drapeau indiquant si une exception est une exception cliente. Ensuite, vous pourriez avoir votre vérification de filtre pour l'existence du drapeau.
J'aime cette approche pour quelques raisons.
Tout d'abord, il échoue en toute sécurité. Si quelqu'un n'explique pas l'explicitement jetter une clienteException, les détails de l'exception ne sont pas signalés. Oublier d'afficher quelque chose est un problème moindre que d'afficher accidentellement quelque chose.
Deuxièmement, il permet de déterminer s'il faut afficher l'exception à effectuer à la bonne place. Toutes les idées IOExceptions ne sont pas affichées, par exemple. Certains peuvent être, et d'autres ne seront pas. Les exceptions spécifiques peuvent être capturées et transformées n'importe où dans la pile d'appels, de sorte que la transmation puisse être faite à un endroit où elle est connue pour être correcte.
Les deux choses ensemble signifient que un futur développeur ne changera pas de manière insiable toute une classe d'exception à afficher ou de penser que quelque chose ne sera pas affiché lorsqu'il sera réellement.
De plus, le but de l'utilisation d'un type d'exception particulier consiste à déterminer ultérieurement quelles mesures prennent en réponse à cette exception. "Afficher ce message à l'utilisateur" est une action parfaitement bonne pour spécifier. Une fois que cette décision a été faite, la nature exacte de l'exception est complètement négligente. (Le problème initial peut être mis dans la propriété InnerException, bien sûr.)
Donc, à mon avis, c'est un bon design.
Mes préoccupations avec cette solution sont que très probablement ces exceptions seront généralement projetées par des objets dans une couche d'entreprise (ou des objets de modèle dans la terminologie MVC). L'utilisation que vous décrivez est vraiment ce que je considérerais comme une préoccupation de présentation.
En règle générale, vous auriez besoin de repenser quelle que soit l'exception que vous avez dans votre modèle, uniquement pour communiquer si l'exception peut ou non être exposée à l'utilisateur ou non. Que pensez-vous que l'utilisateur fasse avec les informations? Si l'utilisateur peut résoudre la situation, il ne devrait pas y avoir d'exception pour que l'état commence par?
Je sert à attraper des exceptions spécifiques par cas et à prendre des décisions de présentation sur place. Vous pouvez envoyer une exception, comme attrapé, utilisé comme modèle à une vue. Je laisserais toujours le contrôleur décider, pas quiconque jette l'exception.