J'ai créé des exceptions pour chaque condition à laquelle mon application ne s'attend pas. UserNameNotValidException , PasswordNotCorrectException etc.
Cependant, on m'a dit que je ne devais pas créer d'exceptions pour ces conditions. Dans mon UML, ce sont des exceptions au flux principal, alors pourquoi ne pas créer d'exception ?
Des conseils ou des bonnes pratiques pour créer des exceptions ?
Ma ligne directrice personnelle est la suivante : une exception est levée lorsqu'une hypothèse fondamentale du bloc de code en cours s'avère fausse.
Exemple 1 : disons que j'ai une fonction qui est censée examiner une classe arbitraire et retourner vrai si cette classe hérite de List<>. Cette fonction pose la question suivante : "Cet objet est-il un descendant de List ?". Cette fonction ne devrait jamais lever une exception, car il n'y a pas de zones grises dans son fonctionnement - chaque classe unique hérite ou non de List<>, donc la réponse est toujours "oui" ou "non".
Exemple 2 : disons que j'ai une autre fonction qui examine une List<> et renvoie true si sa longueur est supérieure à 50, et false si la longueur est inférieure. Cette fonction pose la question "Cette liste a-t-elle plus de 50 éléments ?". Mais cette question fait une supposition - elle suppose que l'objet qui lui est donné est une liste. Si je lui donne un NULL, alors cette supposition est fausse. Dans ce cas, si la fonction renvoie soit vrai o faux, alors il enfreint ses propres règles. La fonction ne peut pas retourner tout ce qui est et prétendre qu'il a répondu correctement à la question. Donc il ne revient pas - il lève une exception.
Ce chiffre est comparable à celui de l "question tendancieuse" une erreur logique. Chaque fonction pose une question. Si l'entrée qui lui est donnée rend cette question fallacieuse, alors elle lève une exception. Cette ligne est plus difficile à tracer avec les fonctions qui retournent void, mais l'essentiel est que si les hypothèses de la fonction sur ses entrées sont violées, elle doit lancer une exception au lieu de retourner normalement.
L'autre aspect de cette équation est le suivant : si vous constatez que vos fonctions lèvent fréquemment des exceptions, vous devez probablement affiner leurs hypothèses.
Exactement ! Une exception est levée lorsque et seulement lorsque les conditions préalables de la fonction (hypothèses sur les arguments) sont brisés !
En linguistique, on appelle parfois cela échec du présupposé . L'exemple classique est dû à Bertrand Russell : "Le roi de France est-il chauve" ne peut pas recevoir de réponse par oui ou par non, (resp. "Le roi de France est chauve" n'est ni vrai ni faux), parce qu'il contient une fausse présupposition, à savoir qu'il existe un roi de France. L'échec de présupposition est souvent vu avec des descriptions définies, et c'est courant lors de la programmation. Par exemple, "La tête d'une liste" a une défaillance de présupposition lorsqu'une liste est vide, et il est alors approprié de lancer une exception.
Parce que ce sont des choses qui vont se produire normalement. Les exceptions ne sont pas des mécanismes de flux de contrôle. Les utilisateurs se trompent souvent de mot de passe, ce n'est pas un cas exceptionnel. Les exceptions devraient être une chose vraiment rare, UserHasDiedAtKeyboard des situations de ce type.
Hmm, non. Les exceptions peuvent être utilisées comme mécanismes de flux de contrôle si les performances maximales ne sont pas requises, ce qui est le cas de la plupart des applications web. Python utilise l'exception 'StopIteration' pour terminer les itérateurs, et cela fonctionne très bien. Le coût n'est rien comparé aux IO, etc.
+1 excellente réponse. Je suis tellement frustré par les développeurs qui travaillent sur les API que je dois consommer et lancer des exceptions pour chaque petite chose. TRES peu de cas nécessitent vraiment des exceptions. Si vous avez défini 25 types d'exceptions différents, réexaminez votre conception, il se peut que vous vous y preniez mal.
Devrait-il y avoir une exception lorsque l'utilisateur tente une action illégale qu'il n'est pas autorisé à faire en manipulant le code de la page web, par exemple en supprimant les messages de quelqu'un d'autre ici à StackOverflow ?
Mes petites directives sont fortement influencées par le grand livre "Code complet" :
Il n'y a PAS d'exception si le nom d'utilisateur n'est pas valide ou si le mot de passe n'est pas correct. Ce sont des choses auxquelles vous devez vous attendre dans le cadre d'un fonctionnement normal. Les exceptions sont des choses qui ne font pas partie du fonctionnement normal du programme et qui sont plutôt rares.
Je n'aime pas utiliser les exceptions car on ne peut pas savoir si une méthode lève une exception juste en regardant l'appel. C'est pourquoi les exceptions ne devraient être utilisées que si vous ne pouvez pas gérer la situation de manière décente (pensez à "out of memory" ou "computer is on fire").
" Je n'aime pas utiliser les exceptions car on ne peut pas savoir si une méthode lève une exception juste en regardant l'appel. "C'est pourquoi il existe des exceptions vérifiées pour les langages qui les supportent.
Les exceptions vérifiées ont leur propre lot de problèmes. Je préfère encore utiliser des exceptions pour des "circonstances exceptionnelles", et non pour des choses qui font partie du flux de travail normal.
En réponse à votre édition. Je mets toujours dans mes docs xml à la fin de la section résumé les exceptions que la fonction lève afin que je puisse voir cette information dans intellisense.
Une règle de base est d'utiliser les exceptions dans le cas de quelque chose que vous ne pourriez normalement pas prévoir. Par exemple, la connectivité de la base de données, un fichier manquant sur le disque, etc. Pour les scénarios que vous pouvez prévoir, par exemple les utilisateurs qui tentent de se connecter avec un mauvais mot de passe, vous devez utiliser des fonctions qui renvoient des booléens et savoir comment gérer la situation avec élégance. Vous ne voulez pas interrompre brusquement l'exécution en lançant une exception juste parce que quelqu'un a mal saisi son mot de passe.
Il n'est pas nécessaire d'arrêter l'exécution du programme lors d'une exception... lancez l'exception, l'appelant attrape alors l'exception et doit la gérer, si possible, enregistrer une erreur et continuer. Il n'est pas correct de continuer à lancer des exceptions dans la pile d'appels - il faut les attraper là où elles se produisent et les traiter à cet endroit.
Mais pourquoi les lancer si on peut les gérer directement. si le mot de passe est faux ou quoi que ce soit d'autre, je laisse juste un if retourner un false et donner une erreur.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
76 votes
Veuillez rouvrir le dossier, il s'agit d'une question très sensée et valable. Toute question implique une certaine quantité d'opinion, mais dans ce cas-ci
12 votes
Je suis également d'accord pour que cette question soit rouverte car elle est liée aux meilleures pratiques. D'ailleurs, les meilleures pratiques sont toujours des opinions qui peuvent aider les autres.
6 votes
Microsoft dit : "Ne pas renvoyer de codes d'erreur. Les exceptions sont le principal moyen de signaler les erreurs dans les frameworks" et "...Si un membre ne peut pas réussir à faire ce qu'il est censé faire, cela doit être considéré comme un échec d'exécution et une exception doit être levée". msdn.microsoft.com/library/ms229030%28v=vs.100%29.aspx
8 votes
Il peut s'agir d'exceptions tout à fait raisonnables, mais cela dépend des méthodes qui les lancent. Une méthode appelée
IsCredentialsValid(username,password)ne doit pas lever une exception si le nom d'utilisateur ou le mot de passe est invalide, mais renvoyer false. Mais disons qu'une méthode qui lit les données de la base de données pourrait légitimement lancer une telle exception, si l'authentification échoue. En résumé : vous devriez lever une exception si une méthode n'est pas en mesure d'accomplir la tâche qu'elle est censée accomplir.0 votes
En général, les exceptions doivent être utilisées si la fonction qui constate l'erreur ne peut pas s'en remettre.
0 votes
@Matsen75 Puisque les frameworks utilisent généralement la POO, les exceptions doivent être utilisées au lieu des erreurs car les exceptions sont la manière de la POO de gérer quelque chose d'imprévisible. Dans l'ancienne programmation procédurale, les erreurs étaient le moyen de gérer les circonstances imprévisibles. Les erreurs peuvent donc être considérées comme l'ancienne implémentation des exceptions. Par conséquent, en PHP, les erreurs et les exceptions sont définies comme des interfaces "throwable" et peuvent donc être utilisées de manière interchangeable. Cependant, il est recommandé de ne pas les mélanger. De même, les coupures comme "do stuff or die(errormsg)" doivent être évitées.