Utilisation de NotImplementedException


15

Est-ce considéré comme une mauvaise pratique de jeter NotImplementedExceptiondu code que vous n'avez pas encore écrit? Peut-être que les commentaires TODO seraient considérés comme plus sûrs?


6
Quel serait l'inconvénient d'utiliser ces exceptions pour vous?
SRKX

@SRKX Il existe un risque d'exceptions entrant dans le code de production et entraînant le dysfonctionnement de l'ensemble du bloc de code. (cela ne m'est pas encore arrivé mais nous avons tous des jours de congé) Je les utilise personnellement, j'étais inquiet d'avoir pu ignorer certains des inconvénients.
Tom Squires

Curieusement, aucune des balises ne spécifie la langue utilisée. Cela ne s'applique pas à tous les langages communs, car C n'a aucune sorte d'exceptions. Il y a de la place pour une étiquette de langue ici, les gars.
David Thornley

1
@DavidThornley, la question était à l'origine taguée comme C #, j'ai donc lu la balise.
svick

@svick: Je pensais que c'était probablement C #. Merci d'avoir ajouté le tag.
David Thornley

Réponses:


34

Je pense que NotImplementedExceptionc'est en fait une bonne pratique.

En effet, si vous oubliez d'implémenter une méthode, et que vous l'utilisez plus tard dans votre projet (et croyez-moi, cela arrive), vous pourriez passer beaucoup de temps à déboguer à chercher ce qui s'est mal passé pas à pas. Si vous avez l'exception, le programme s'arrêtera directement, provoquant l'exception (si vous interceptez l'exception, vous la trouverez rapidement en recherchant quelle exception vous avez interceptée).

Je recommanderais d'utiliser les commentaires NotImplementedException combinés avec TODO, de cette façon, vous combinez l'aide de l'interface graphique (avec les tâches dans VS) et la sécurité du programme.

Pour la version finale, c'est encore plus important à mon avis, car dans la plupart des cas, vous préféreriez que votre programme plante plutôt que d'avoir un programme qui fonctionne apparemment correctement mais produise des résultats erronés.


6
Si vous utilisez Resharper, il affiche NotImplementedExceptions de la même manière que les commentaires TODO. Je pense que c'est une fonctionnalité intéressante.
svick

1
Ajoutez quelques bonnes pratiques TDD et vous avez un gagnant
LRE

7

Cela dépend de votre philosophie générale concernant les erreurs et la gestion des erreurs. Je suis du genre "erreur grave": je vais lancer une exception au moindre indice que quelque chose pourrait mal tourner; J'affirmerai tout; S'il y a une erreur, si quelque chose devait être là, et ce n'est pas le cas, ou si quelque chose est là, et ça ne devrait pas, l'univers entier doit s'arrêter. Le son d'exclamation des fenêtres doit sonner de façon inquiétante à travers les haut-parleurs.

Il y a d'autres personnes qui préfèrent ne pas se soucier des erreurs. Que se passe-t-il si nous l'envoyons au client et que le module de rapports complet est manquant parce que nous avons oublié de le coder et que personne lors des tests ne s'en est rendu compte, car l'application était trop silencieuse à ce sujet? Mieux vaut ne rien faire, que de jeter une exception au visage du client!


C'est comme si vous souhaitiez un comportement différent dans Debug et Release, et une assertion ne le coupera pas toujours. Je crois que les contrats de code .Net peuvent être désactivés dans la version.
Job

1
J'utilise principalement des assertions, qui sont également désactivées dans la version. J'ai ma propre fonction d'assertion qui atteint un point d'arrêt dans le débogage, lève une exception lors des tests ou ne compile même pas à la sortie.
Mike Nakis

3

Je dirais que c'est une bonne idée. Habituellement, je vois ces exceptions levées par du code squelette qui est généré automatiquement à partir d'un formulaire ou d'un diagramme ou quelque chose. L'exception me rappelle d'implémenter le code, et elle garantit qu'il y aura des erreurs si j'essaie d'utiliser la fonctionnalité qui a été configurée mais jamais complètement implémentée. Parfois, je vais le supprimer ou le remplacer par quelque chose qui est moins susceptible d'arrêter l'exécution (comme imprimer un avertissement sur la console), mais je trouve que cela fonctionne pour moi.

Si vous créez une bibliothèque que d'autres utiliseront, cette exception est meilleure que l'alternative, qui serait un utilisateur de votre bibliothèque appelant une fonction et se demandant pourquoi rien ne semblait se produire. Bien sûr, il est encore assez mauvais d'avoir cette exception dans une bibliothèque livrée mais mieux que les échecs silencieux, IMO.


1

Je pense que c'est une bonne pratique. L'alternative consiste à propager une valeur ou un état non valide, ce qui va affecter à la fois le code de test et de production.


1
Attendez .... vous voulez dire, où vous travaillez, le code qui jette NotImpl se rendrait à l'AQ? Même en production?
Steven Evers

3
Non, juste le contraire: un NotImpl est un énorme énorme drapeau rouge / condition d'erreur. Mais les TODO n'ont pas de valeur sémantique et peuvent en faire un test ou une production, gâchant tranquillement les choses. (Je pourrais imaginer une politique d'élimination des TODO de la production, mais nous n'avons pas une telle règle.)
Larry OBrien

1

J'utilise toujours NotImplementedException- c'est à ça qu'il sert , après tout.

Cela est lié au concept de «échec rapide»: si votre code lève une exception, cela devrait être détecté avant de passer en production. S'il parvient à la production, le client sait au moins que l'assemblage est incorrect .

Si le code renvoie une valeur vide de sens ou, pour les voidméthodes, ne prend aucune mesure, les consommateurs de votre code peuvent raisonnablement penser que l'appel était significatif alors qu'il ne l'était pas. Ensuite, plus tard, lorsqu'ils obtiennent du code correct, leur code peut se casser car cela dépend de l'ancien comportement incorrect.


0

De quel genre de projet s'agit-il? Au travail ou à la maison? À la maison, faites ce que vous voulez - ce qui vous rappelle le mieux que vous devez terminer tout ce sur quoi vous travaillez.

Au travail, finissez de l'écrire.

Je ne peux pas voir une situation où j'archiverais du code qui peut / cassera d'autres développeurs, QA ou une build.


Eh bien les deux, j'essaie aussi de respecter les bonnes pratiques à la maison.
Tom Squires

0

Je fais les deux I mais un \ todo dans mon autodocage doxygene, puis je lance l'exception. De cette façon, si les gens ne peuvent pas être dérangés par RTFM au moins, ils seront en mesure de comprendre pourquoi leur programme a planté, au lieu de se demander pourquoi il existe une fonction déclarée qui ne renvoie pas de valeur logique.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.