Je viens de trouver dans un projet:
try
{
myLabel.Text = school.SchoolName;
}
catch
{
myPanel.Visible = false;
}
9 Réponses :
Je pense que c'est mauvais car il est codant contre une exception pour une et elle héritera également des frais généraux inutiles. Les exceptions ne doivent être prises que si elles vont être traitées de manière spécifique.
Les exceptions doivent être prises spécifiquement pour des cas exceptionnels que vous ne pouvez pas prédire, dans ce cas, il s'agit d'un simple vérification de voir si l'école peut être null, elle devrait en fait que l'école puisse être null (puisque l'étiquette n'est pas définie ). Si l'école était nulle et que cela n'aurait pas dû être qu'il ne devrait y jeter sa propre argumentation.
Devrait être une chaîne vide cependant, pas null.
@Billyonéal, l'école est un objet auquel il est potentiel d'être null dans ce cas, c'est là que l'exception se produirait.
Je n'aime jamais utiliser des exceptions pour le contrôle de flux. Les exceptions sont chères et il est difficile de déterminer le flux réel d'un programme avec des exceptions pour atteindre d'autres endroits en code. Pour moi, c'est comme utiliser goto. Cela ne signifie pas que vous devriez éviter les exceptions, mais une exception devrait être une exception à une exception à ce qui devrait normalement arriver dans le programme.
Je pense qu'une partie pire du code est que cela ne fait même rien avec l'exception. Il n'y a pas de journalisation ni d'explication de la raison pour laquelle l'exception est lancée.
En .NET, les exceptions ne sont pas vraiment aussi chères, à moins que vous ne receviez la trace de la pile. Dans ce scénario spécifique, il serait difficile de montrer que cette manipulation d'exception a entraîné une question de performance.
Dans la grande portée des choses, ils ne sont pas aussi chers, mais ils sont comparés à si (Null == MyLabel).
Vous ne devez pas utiliser des exceptions pour le flux de contrôle simplement parce que c'est une mauvaise conception. Cela n'a pas de sens. Les exceptions concernent des cas exceptionnels, pas pour un flux normal. La performance ne sera probablement pas une question dans cette situation, car pour la plupart des applications modernes sur le matériel moderne, vous pouvez lancer des exceptions toute la journée et que l'utilisateur ne remarquerait pas une performance touchée. Toutefois, s'il s'agit d'une application de performance élevée, un traitement de nombreuses données ou une certaine sorte de travail, alors oui, la performance serait une préoccupation.
Vous avez absolument raison de dire que c'est mauvais. C'est mauvais parce qu'il défie l'intention Je me rends compte qu'il y a de la place pour différents styles de programmation, mais personnellement, je pense que même si cela fonctionne, et je peux voir ce que le code tente de faire, cela fait aussi mal la lisibilité et la clarté du code, ce qui en fait que le fait de la rendre plus difficile pour les programmeurs de maintenance à suivre. Une déclaration si elle est beaucoup plus appropriée ici.
Lancer des exceptions a un impact négatif sur la performance, voir
Je pense que si vous obtenez technique à ce sujet, la capture des exceptions est la partie coûteuse. Mais cela n'a pas d'importance, le succès de la performance est là.
C'est ce que j'essayais vraiment de demander: abomination contre la programmation ou techniquement bien que nous ne jetons pas l'exception. +1 commentaire.
Les exceptions contractent les frais généraux d'exécution, mais il est probablement négligeable ici. Il y aura une différence en cours d'exécution dans le débogueur, mais les binaires construits doivent courir à peu près la même vitesse.
Indiquez à votre développeur que tout chimpanzé peut faire du code que la machine peut lire. Un bon code est écrit pour les êtres humains, pas des machines. Si une exception nulle est la seule chose qui vous inquiète, c'est probablement un bogue dans le code de l'utilisateur - personne ne doit jamais essayer d'attribuer NULL à quelque chose de cette façon. Utilisez un assert () instruction à la place.
J'aimerais pouvoir donner à cela un +6 pour "bon code est écrit pour les êtres humains, pas les machines."! Je suis arrivé à la conclusion que toute la différence entre un programmeur junior et une personne âgée est cette déclaration.
À mon avis, cela est faible car il pourrait être fait beaucoup plus clair avec une instruction IF:
if (school != null) {
myLabel.Text = school.SchoolName;
}
else {
myPanel.Visible = false;
}
Découvrez ce Post sur "Pourquoi ne pas utiliser des exceptions comme un flux de contrôle régulier? "
C'est plus ou moins ce que j'ai passé la matinée à chercher - merci pour le lien, mais vous devriez probablement expliquer un peu ce que votre lien est ou pourquoi il est pertinent, de sorte que d'autres utilisateurs puissent la lire. D'autres utilisateurs: c'est un lien avec une question bien considérée comme intitulée "Pourquoi ne pas utiliser d'exceptions comme un flux de contrôle régulier?"
Je suis d'accord avec tout le monde ici - c'est une idée horrible.
Il y a quelques cas à Java (je pense qu'ils sont principalement partis maintenant, mais il y en a peut-être certains dans des bibliothèques externes) où vous deviez avoir une exception pour certains cas «non exceptions».
En général, lorsque vous écrivez le code de la bibliothèque (Eh bien, toute classe en fait), évitez d'utiliser des exceptions pour tout ce qui pourrait être évité. S'il est possible qu'un champ de nom ne soit défini et qui devrait provoquer une exception dans une méthode d'écriture (), assurez-vous d'ajouter une méthode isvalid () afin de ne pas avoir à saisir l'exception autour de l'écriture à savoir Il y a un problème.
(Bad Java Code Addendum): Ce style de programmation "Good" élimine pratiquement tout besoin d'exceptions vérifiées dans Java et des exceptions vérifiées en Java sont la succion.
Stackoverflow.com/questions/77127/Quand -à-jeter - une exception / ...