Pourquoi ne pas attraper les Exceptions générales
Mon VS m'a juste dit;
Avertissement 2 CA1031 : Microsoft.Conception : Modifier Le Programme.Main(string[])' pour attraper une exception plus spécifique qu' "Exception" ou relever de l'exception.
Pourquoi devrais-je le faire? Si je le fais, et ne pas attraper toutes les exceptions à gérer, mon programme se bloque avec le populaire rapport à l'écran. Je ne veux pas que mes utilisateurs d'obtenir une telle erreur de la merde!
Pourquoi devrais-je ne pas attraper toutes les exceptions à la fois d'afficher un joli avertissement à l'utilisateur de dire: "quelque Chose s'est mal passé, ne s'en inquiètent pas, je vais y faire face, juste être patient"?
Modifier: Viens de voir que j'ai un dupe ici, désolé pour cette Dupe
Edit2: Pour clarifier les choses; je dois quitter le programme après aucune exception a été attrapé! Je ne veux pas que mon utilisateur de voir que "le rapport à microsoft" boîte de dialogue qui s'affiche quand une exception non gérée s'est soulevée dans une console application!
Vous devez vous connecter pour publier un commentaire.
Avaler des exceptions est une pratique dangereuse, car:
Comme vous pouvez l'imaginer, certains de ces résultats peuvent être extrêmement catastrophique, afin de faire de ce droit est un important habbit.
Meilleures Pratiques
Tout d'abord, le code de la défensive, de sorte que les exceptions ne se produisent pas plus que nécessaire. Ils sont gourmand en ressources.
Gérer le prévu des exceptions à un niveau de granularité (par exemple:
FileNotFoundException
) lorsque cela est possible.Pour les exceptions inattendues, vous pouvez faire une des deux choses:
Échouer Gracieusement?
Disons que vous travaillez dans ASP.Net et vous ne voulez pas afficher le jaune de l'écran de la mort de vos utilisateurs, mais vous ne voulez pas de problèmes cachés de l'équipe de dev.
Dans nos applications, nous avons l'habitude attraper les exceptions non gérées dans
global.asax
et puis faire de journalisation et d'envoyer des emails de notification. Nous montrons aussi plus conviviale page d'erreur, qui peut être configurée dansweb.config
à l'aide de lacustomErrors
tag.C'est notre dernière ligne de défense, et si nous finissons obtenir un e-mail nous sauter dessus tout de suite.
Ce type de modèle est pas le même que juste avaler des exceptions, si vous avez un vide bloc Catch qui existe uniquement pour "faire semblant" que l'exception n'a pas eu lieu.
Autres Notes
Dans VS2010, il y a quelque chose qui s'appelle intellitrace à venir qui va vous permettre de réellement courriel de l'état de l'application de retour à la maison et le code pas à pas, examiner les valeurs des variables au moment de l'exception, et ainsi de suite. Cela va être extrêmement utile.
Parce que les programmes qui l'hirondelle (capture) des exceptions au hasard, (et puis continuer), ne peut être invoquée pour faire ce qu'ils sont censés faire. C'est parce que vous n'avez aucune idée de quel type d'exception a été "ignoré". Que faire si il y avait un dépassement de capacité ou d'erreur d'accès mémoire qui provoque le mauvais montant qui sera débité sur un compte financier? Que si elle tient la barre du navire, dans l'iceberg au lieu de l'en éloigner ? Les défaillances inattendues doit toujours entraîner l'application de résilier. Que les forces du processus de développement afin d'identifier et de corriger les exceptions qu'il trouve, (accidents au cours de démonstrations sont une merveilleuse source de motivation), et, dans la production, permet conçues de manière appropriée, les systèmes de sauvegarde à réagir lorsque le logiciel de l'expérience d'une "inattendu" de l'impossibilité de faire ce qu'il a été conçu pour faire.
EDIT: Pour clarifier les distinctions entre les composants de l'INTERFACE utilisateur, et le service ou middleware componentrs.
En Service ou des composants Middleware, où il n'y a pas d'interaction utilisateur avec le composant de code à partir de l'intérieur du même espace de processus que le code est en cours d'exécution, le composant doit "passer" à l'exception de tout ce composant client imnitiated l'appel qu'elle est en cours de traitement. Peu importe l'exception, il doit faire tous les efforts pour ce faire. C'est toujours le cas, cependant, tjhat dans les cas où un imprévu, ou imprévus exception se produit, le composant doit enfin mettre fin au processus, il est en cours d'exécution. Prévu ou attendu exceptions, un développement de l'analyse devrait être faite pour déterminer si oui ou non, pour le d'exception, le composant et ses processus hôte peut continuer à fonctionner (traitement des demandes futures), ou s'il doit être mis fin.
Vous devez gérer les exacte exceptions que vous êtes capable de gérer et de laisser tous les autres de la bulle vers le haut. Si il affiche un message à l'utilisateur, cela signifie que vous ne sais pas ce que vous pouvez gérer.
Ayant travaillé sur le matériel utilisé par les intervenants en cas d'urgence, je préfère l'utilisateur de voir un vilain message d'erreur que accidentellement avaler une exception qui induit en erreur l'utilisateur en lui faisant croire que tout est "ok". Selon votre application, la conséquence pourrait être rien de rien à une vente perdue à une perte catastrophique de la vie.
Si, une personne va attraper tous les une exception, montrent un meilleur dialogue d'erreur, puis quittez l'application, c'est ok.. mais si ils vont continuer à fonctionner après avoir avalé une exception inconnue, je mettrait le feu à une personne pour qui. Ce n'est pas ok. Jamais.
Bon codage est à propos des pratiques qui supposent que les humains font des erreurs. En supposant que toutes les "critiques" des exceptions ont été capturées et traitées est une mauvaise idée.
Environment.Exit(2)
)Réponse Simple: vous êtes censé corriger un bug. Trouver l'endroit qui lève l'exception, et qu'il est au-delà de votre contrôle - le réparer.
Aussi attraper (sans renvoi) toutes sortes d'exception viole exception de la neutralité. En général, vous ne voulez pas le faire (bien que d'intercepter les exceptions dans
main
ne ressemble, cas spécial)Depuis votre message d'avertissement indique que c'est dans main(), je vais supposer que dans les niveaux inférieurs, vous ne attraper plus d'Exceptions spécifiques.
Pour main(), j'aimerais envisager deux cas:
Pour ce faire, bien, il suffit de vérifier si le DÉBOGAGE est définie (et de définir, si VS ne le fait pas automatiquement):
J'avais désactiver l'avertissement au sujet de la capture des Exceptions générales, mais seulement pour votre fonction main (), la capture de l'Exception de toute autre méthode est imprudent, comme d'autres affiches ont déjà dit.
Il existe un moyen de de supprimer certains messages à partir de l'analyse de code. J'ai utilisé ce pour cette raison exacte (la capture de l'exception générale pour l'exploitation forestière) et c'est assez pratique. Lorsque vous ajoutez cet attribut, il montre que vous avez au moins reconnu que vous êtes en rupture de la règle pour une raison spécifique. Vous aussi vous obtenez toujours votre avertissement pour les blocs catch sont incorrectes (la capture de l'exception à des fins autres que l'exploitation forestière).
MSDN SuppressMessageAttribute
Lorsque vous attraper les exceptions générales, vous obtenez l'effet secondaire potentiellement cacher des problèmes d'exécution de l'utilisateur qui, à son tour, peut compliquer le débogage. Aussi, par la capture d'exception générale, vous êtes en ignorant un problème (dont vous êtes probablement jeter ailleurs).
Vous pouvez configurer votre try catch pour attraper différents types de comportement et de gérer l'exception fondée sur le genre. Pour la plupart des méthodes et des propriétés dans le cadre, vous pouvez également voir quelles sont les exceptions qu'ils sont capables de le lancer. Donc, sauf si vous êtes l'interception d'une exception d'un très petit bloc de code, vous devriez probablement prendre exceptions spécifiques.
VS, vous pouvez configurer une page d'erreur personnalisée pour montrer vos utilisateurs lorsque quelque chose va mal, au lieu de l'attraper dans un try-catch. Je suppose que depuis que vous utilisez VS que vous êtes à l'aide d'ASP .NET. Si oui, ajouter ce tag à votre site Web.La Config dans le Système.Web tag:
Vous pouvez également attraper toutes les exceptions non traitées dans le monde.asax fichier (si vous ne l'avez pas déjà: clic-Droit sur le projet web, sélectionnez Ajouter un Élément, et recherche pour cela). Il ya un tas d'application large de gestionnaires d'événements dans ce fichier comme "Application_Error" qui attrape tous les une exception qui n'est pas pris au sein de votre application de sorte que vous n'avez pas à utiliser Try-Catch de tous les temps. C'est bon à utiliser pour vous envoyer un e-mail si une exception se produit et, éventuellement, de les rediriger vers votre page d'accueil ou quelque chose si vous ne souhaitez pas utiliser le customErrors tag ci-dessus.
Mais en fin de compte vous ne voulez pas envelopper la totalité de votre application dans un try-catch, ni voulez-vous d'attraper une Exception générale. Essayez-les captures sont généralement de ralentir votre application et beaucoup de temps si vous attraper toutes les exceptions générales qu'il pourrait être possible que vous ne savez pas un bug existe jusqu'à ce que des mois ou des années plus tard, car le try-catch vous a amené à négliger.