Arguments pour ou contre l'utilisation de Try / Catch en tant qu'opérateurs logiques [fermé]


36

Je viens de découvrir un code charmant dans notre application d'entreprise qui utilise des blocs Try-Catch comme opérateurs logiques.
Ce qui signifie "faire du code, si cela génère cette erreur, le fait, mais si cela jette cette erreur, faites cette 3ème chose à la place".
Il utilise "Finally" comme déclaration "else", il apparaît.
Je sais que cela est faux en soi, mais avant d’aller me battre, j’espérais avoir des arguments bien pensés.
Et hé, si vous avez des arguments POUR l’utilisation de Try-Catch de cette manière, veuillez le dire.

Pour tous ceux qui se demandent, le langage utilisé est le C # et le code en question, une trentaine de lignes et cherche des exceptions spécifiques. Il ne gère pas TOUTES les exceptions.


13
Je n’ai que des arguments contre cette pratique, et comme vous semblez déjà convaincu que c’est une mauvaise idée, je ne vais pas me donner la peine de les publier.
FrustratedWithFormsDesigner

15
@FrustratedWIthFormsDesigner: C'est un mauvais raisonnement. Qu'en est-il des personnes qui ne sont pas convaincues? Qu'en est-il de ma question actuelle dans laquelle je demande spécifiquement des raisons étant donné que je ne peux pas vraiment dire "pourquoi" mais juste que je sais que c'est faux.
James P. Wright

3
Mon opinion dépend fortement de ce que le code en question fait réellement. Il y a des choses qui ne peuvent pas être vérifiées à l'avance (ou permettent des conditions de concurrence lorsque vous essayez, telles que de nombreuses opérations de fichier - dans le délai entre la vérification et l'opération, tout peut arriver au fichier) et doit être try'd. Tous les cas exceptionnels qui justifient une exception en général ne doivent pas nécessairement être fatals dans ce cas particulier. Alors, pourriez-vous le faire d'une manière plus simple, plus uniforme ou plus robuste sans utiliser d'exceptions?

11
J'espère qu'ils n'utilisent pas vraiment le bloc "finally" comme un "else" car le bloc "finally" est toujours exécuté après le code précédent, quelles que soient les exceptions générées.
jimreed

2
Quelle langue utilisent-ils? Par exemple, OCaml convient parfaitement, où la bibliothèque standard génère régulièrement des exceptions. La gestion des exceptions est très bon marché là-bas. Mais ce ne sera pas aussi efficace en CLI ou JVM.
SK-logic le

Réponses:


50

La gestion des exceptions a tendance à être un moyen coûteux de gérer le contrôle de flux (certainement pour C # et Java).

Le moteur d'exécution fait beaucoup de travail lorsqu'un objet d'exception est construit - rassembler la trace de la pile, déterminer où l'exception est gérée et plus encore.

Tout cela coûte en mémoire et en ressources CPU qu'il n'est pas nécessaire d'étendre si des instructions de contrôle de flux sont utilisées pour le contrôle de flux.

De plus, il y a un problème sémantique. Les exceptions concernent des situations exceptionnelles et non un contrôle de flux normal. Vous devez utiliser la gestion des exceptions pour gérer des situations imprévues / exceptionnelles, et non comme un flux de programme normal, car sinon, une exception non capturée vous en dira beaucoup moins.

En dehors de ces deux-là, il y a le problème des autres lecteurs du code. L'utilisation d'exceptions de cette manière n'est pas ce à quoi la plupart des programmeurs s'attendent. Par conséquent, la lisibilité et la compréhensibilité de votre code en pâtissent. Quand on voit "Exception", on se dit que quelque chose de mauvais est arrivé, quelque chose qui n’est pas censé se produire normalement. L'utilisation d'exceptions de cette manière est donc source de confusion.


1
Un bon point sur les performances, même si cela dépendra aussi des spécificités de la plate-forme.
FrustratedWithFormsDesigner

4
Si c'est le seul inconvénient, eh bien, je vais baisser les performances tous les jours si cela m'achète un meilleur code (sauf dans les chemins critiques en termes de performances, mais heureusement, cela ne représente que 20% de tout le code, même dans les applications généralement performantes. -critique).

5
@delnan - Non, pas le seul inconvénient.
Oded

2
Autre que le mot inattendu, je suis d’accord avec votre message. Votre code contient parfois des exceptions. La plupart d'entre eux doivent être prévisibles, comme des échecs de connexion avec la base de données ou un appel de service, ou à tout moment si vous utilisez du code non géré. Vous attrapez des problèmes indépendants de votre volonté et vous les résolvez. Mais je conviens que vous ne devriez jamais avoir de contrôle de flux basé sur des exceptions que vous pouvez éviter dans votre code.
SoylentGray

4
"La gestion des exceptions tend à être un moyen coûteux de gérer le contrôle de flux". Faux pour Python.
S.Lott

17

Je viens de découvrir un code charmant dans notre application d'entreprise qui utilise des blocs Try-Catch comme opérateurs logiques. Ce qui signifie "faire du code, si cela génère cette erreur, le fait, mais si cela jette cette erreur, faites cette 3ème chose à la place". Il utilise "Finally" comme "else", il apparaît. Je sais que c'est faux intrinsèquement ...

Comment sais-tu ça? J'ai abandonné toute cette sorte de "connaissance" et je crois maintenant que le code le plus simple est le meilleur. Supposons que vous souhaitiez convertir une chaîne en un élément facultatif qui est vide si l'analyse échoue. Il n'y a rien de mal avec:

try { 
    return Optional.of(Long.valueOf(s)); 
} catch (NumberFormatException) { 
    return Optional.empty(); 
}

Je suis complètement en désaccord avec l'interprétation habituelle de "Les exceptions sont des conditions exceptionnelles". Lorsqu'une fonction ne peut pas retourner une valeur utilisable ou qu'une méthode ne peut pas répondre à ses post-conditions, lève une exception. Peu importe la fréquence à laquelle ces exceptions sont levées jusqu'à ce qu'il y ait un problème de performances démontré.

Les exceptions simplifient le code en permettant de séparer le traitement des erreurs du flux normal. Il suffit d'écrire le code le plus simple possible, et s'il est plus facile d'utiliser try-catch ou de lever une exception, faites-le.

Les exceptions simplifient les tests en réduisant le nombre de chemins dans le code. Une fonction sans branche complétera ou lèvera une exception. Une fonction avec plusieurs ifinstructions pour vérifier les codes d'erreur a plusieurs chemins possibles. Il est très facile de se tromper ou d’oublier complètement l’une des conditions, de façon à ignorer une condition d’erreur.


4
Je pense que c'est en fait un très bon argument. Votre code est propre et concis et donne un sens à ce qu’il fait. En fait, cela ressemble à ce qui se passe dans le code que je vois, mais il est beaucoup plus complexe, est imbriqué et couvre plus de 30 lignes de code.
James P. Wright le

@ James: on dirait que le code conviendrait si vous extrayiez des méthodes plus petites.
kevin cline

1
On pourrait soutenir que Java pourrait vraiment utiliser quelque chose de plus semblable à TryParse de C #. En C #, ce code serait int i; if(long.TryParse(s, out i)) return i; else return null;. TryParse renvoie false si la chaîne n'a pas pu être analysée. S'il peut être analysé, il définit l'argument de sortie sur les résultats de l'analyse et renvoie true. Aucune exception ne se produit (même en interne dans TryParse) et en particulier aucune exception d'un type qui signifie une erreur de programmation, comme l'indique FormatExceptiontoujours .NETs .
Kevin Cathcart le

1
@ Kevin Cathcart, mais pourquoi est-ce mieux? le code qui attrape l'exception NumberFormatException est beaucoup plus évident pour moi que de vérifier le résultat de TryParse pour une valeur null.
Winston Ewert le

1
@ChrisMiskowiec, je soupçonne que celui que vous trouvez le plus clair est à peu près une affaire de ce que vous êtes habitué. Je trouve qu'il est beaucoup plus facile de suivre l’exception, puis de vérifier les valeurs magiques. Mais c'est tout subjectif. Objectivement, je pense que nous devrions préférer les exceptions car elles ont un défaut normal (planter le programme), plutôt qu'un défaut qui cache un bogue (continuer comme si rien ne s'était passé). Il est vrai que .NET fonctionne mal avec des exceptions. Mais c'est le résultat de la conception de .NET, pas la nature des exceptions. Si sur .NET, oui, vous devez le faire. Mais en principe, les exceptions sont meilleures.
Winston Ewert

12

Le travail de débogage et de maintenance est très difficile lorsque le flux de contrôle est effectué à l'aide d'exceptions.

De manière inhérente, les exceptions sont conçues pour être un mécanisme permettant de modifier le flux de contrôle normal de votre programme - d’exécuter des activités inhabituelles, entraînant des effets secondaires inhabituels, comme moyen de sortir d’une situation particulièrement difficile qui ne peut être gérée avec moins de complication. veux dire. Les exceptions sont exceptionnelles. Cela signifie que, selon l'environnement dans lequel vous travaillez, l'utilisation d'une exception pour un flux de contrôle régulier peut entraîner:

  • Inefficacité Les obstacles supplémentaires que l'environnement doit franchir pour effectuer en toute sécurité les changements de contexte relativement difficiles nécessaires pour les exceptions nécessitent de l'instrumentation et des ressources.

  • Problèmes de débogage Parfois utiles (lors de la tentative de débogage d'un programme), des informations sont projetées par la fenêtre lorsque des exceptions se produisent. Vous pouvez perdre la trace de l’état ou de l’historique du programme pour comprendre le comportement au moment de l’exécution

  • Problèmes de maintenance Le flux d'exécution est difficile à suivre lors de sauts d'exception. Au-delà de cela, une exception peut être levée à l'intérieur d'un code de type boîte noire, qui peut ne pas se comporter de manière simple à comprendre lors du lancement d'une exception.

  • Mauvaises décisions en matière de conception Les programmes ainsi conçus encouragent un état d'esprit qui, dans la plupart des cas, ne permet pas facilement de résoudre les problèmes avec élégance. La complexité du programme final décourage le programmeur de comprendre pleinement son exécution et encourage la prise de décisions conduisant à des améliorations à court terme avec des coûts élevés à long terme.


10

J'ai vu ce modèle utilisé plusieurs fois.

Il y a 2 problèmes majeurs:

  • C'est extrêmement coûteux (instanciation de l'objet exception, collecte de la pile d'appels, etc.). Certains compilateurs pourront peut-être l'optimiser, mais je ne compte pas sur cela dans ce cas, car les exceptions ne sont pas destinées à une telle utilisation. Vous ne pouvez donc pas vous attendre à ce que les gens optimisent leur utilisation.
  • Utiliser des exceptions pour contrôler le flux est en fait un saut, un peu comme un goto. Les sauts sont considérés comme nuisibles pour un certain nombre de raisons. Ils devraient être utilisés si toutes les alternatives présentent des inconvénients considérables. En fait, dans tout mon code, je ne me souviens que de 2 cas, où les sauts étaient clairement la meilleure solution.

2
Il suffit de le signaler, si / else est également considéré comme un saut. La différence est que c'est un saut qui ne peut se produire qu'à cet endroit spécifique (et qui se lit beaucoup plus facilement) et vous n'avez pas à vous soucier du nom des étiquettes (que vous n'avez pas à essayer / attraper) , mais en comparant à goto). Mais simplement dire "c'est un saut qui est mauvais" dit aussi que si / sinon c'est mal, alors que ce n'est pas le cas.
Jsternberg

1
@jsternbarg: Oui, si / else est en fait compilé en sauts au niveau de la machine, mais au niveau de la langue, la cible du saut est l'instruction suivante, alors que dans le cas des boucles, il s'agit de l'instruction en cours. Je dirais que c'est plus un pas qu'un saut;)
back2dos

9

Parfois, les exceptions sont les plus rapides. J'ai vu des cas où les exceptions d'objet nul étaient plus rapides, même en Java, que l'utilisation de structures de contrôle (je ne peux pas citer l'étude pour le moment, vous devrez donc me faire confiance). Le problème survient lorsque Java doit prendre le temps nécessaire et renseigner la trace de pile d'une classe d'exceptions personnalisée au lieu d'utiliser des classes natives (qui semblent être au moins partiellement mises en cache). Avant de dire que quelque chose est unilatéralement plus rapide ou plus lent, il serait bon de procéder à une analyse comparative.

En Python, non seulement il est plus rapide, mais il est beaucoup plus correct de faire quelque chose qui pourrait provoquer une exception puis de gérer l'erreur. Oui, vous pouvez appliquer un système de types, mais cela va à l’encontre de la philosophie du langage; vous devriez simplement essayer d’appeler la méthode et d’attraper le résultat! (Tester si un fichier est accessible en écriture est similaire - essayez simplement d’écrire et attrapez l’erreur).

J'ai vu des moments où il est plus rapide de faire quelque chose de stupide, comme des tables de requête qui n'existaient pas, plutôt que de déterminer si une table existe en PHP + MySQL (la question de savoir où je compare cette question est en fait ma seule réponse acceptée avec des votes négatifs). .

Cela dit, le recours aux exceptions devrait être limité pour plusieurs raisons:

  1. Ingestion accidentelle des exceptions imbriquées. C'est majeur. Si vous attrapez une exception profondément imbriquée que quelqu'un d'autre essaie de gérer, vous venez de tirer sur votre collègue programmeur (peut-être même vous!) Dans le pied.
  2. Les tests deviennent non évidents. Un bloc de code comportant une exception peut présenter un problème parmi plusieurs choses. Un booléen, en revanche, bien que théoriquement cela puisse être gênant de déboguer, ce n’est généralement pas le cas. Cela est d'autant plus vrai que les try...catchadhérents au flux de contrôle (généralement d'après mon expérience) ne suivent pas la philosophie "minimiser le code dans les blocs bloqués".
  3. Cela ne permet pas de else ifbloquer. Assez dit (et si quelqu'un contres avec un "Mais ils pourraient utiliser différentes classes d'exceptions", ma réponse est "Allez dans votre chambre et ne sortez pas avant d'avoir pensé à ce que vous avez dit.")
  4. C'est grammaticalement trompeur. Exception, pour le reste du monde (en tant qu’adhérents à la try...catchphilosophie du contrôle de flux), signifie que quelque chose est entré dans un état instable (bien que peut-être recouvrable). Les états instables sont MAUVAIS et cela devrait nous garder tous éveillés la nuit si nous avons réellement des exceptions évitables (ça me fait peur, pas de mensonges).
  5. Ce n'est pas conforme au style de codage commun. Notre travail, à la fois avec notre code et avec notre interface utilisateur, est de rendre le monde aussi évident que possible. try...catchle contrôle des flux va à l’encontre de ce que l’on considère généralement comme les meilleures pratiques. Cela signifie que le débutant d'un projet prend plus de temps à apprendre le projet, ce qui signifie une augmentation du nombre d'heures de travail sans aucun gain.
  6. Cela conduit souvent à la duplication de code. Enfin, les blocs, bien que cela ne soit pas strictement nécessaire, doivent résoudre tous les pointeurs en suspens laissés ouverts par le bloc try interrompu. Alors essayez des blocs. Cela signifie que vous pouvez avoir un try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}. Dans un if...elsescénario plus traditionnel, il closeSomething()est moins probable (encore une fois, une expérience personnelle) d'être un travail de copier-coller. (Certes, cet argument a plus à voir avec des personnes que j'ai rencontrées qu'avec la philosophie elle-même).

D'après les informations dont je dispose, le problème n ° 6 ne concerne que Java, qui, contrairement à tous les autres langages modernes, ne possède ni fermeture ni gestion des ressources en pile. Ce n'est certainement pas un problème inhérent à l'utilisation des exceptions.
kevin cline

4 et 5 semblent être le même point pour moi. 3-6 ne s'applique pas si votre langage est le python. 1 et 2 sont des problèmes potentiels, mais je pense qu'ils sont gérés en minimisant le code dans le bloc try.
Winston Ewert le

1
@ Winston je ne suis pas d'accord. 1 et 2 sont des problèmes majeurs qui, tout en étant atténués par de meilleures normes de codage, permettent de se demander s'il ne serait peut-être pas préférable d'éviter simplement l'erreur potentielle. 3 s'applique si votre langage est Python. 4-5 peuvent également s'appliquer à Python mais ils ne sont pas obligés de le faire. 4 et 5 sont des points très différents - trompeur est différent des différences stylistiques. Un code trompeur pourrait être quelque chose comme nommer la gâchette pour démarrer un véhicule avec le "bouton d'arrêt". D'un autre côté, sur le plan stylistique, cela pourrait également être analogue à éviter toute indentation de bloc dans C.
cwallenpoole le

3) Python a un bloc else pour les exceptions. Il est extrêmement utile d’éviter les problèmes que vous rencontrez habituellement pour 1 et 2.
Winston Ewert

1
Soyons clairs: je ne préconise pas l’utilisation d’exceptions comme mécanisme général de contrôle des flux. Je préconise de lancer une exception pour tout type de mode "échec", même mineur. Je pense que la version de gestion des exceptions est plus propre et moins susceptible de masquer des bogues que la version de vérification de la valeur de retour. Et idéalement, j'aimerais que les langues rendent plus difficile l'identification des erreurs imbriquées.
Winston Ewert

4

Mon principal argument est que l'utilisation de try / catch pour la logique interrompt le flux logique. Suivre la "logique" à travers des constructions non logiques est (pour moi) contre-intuitif et déroutant. Je suis habitué à lire ma logique comme "si la condition est alors A d'autre B". Lire la même déclaration que "Essayer une capture puis exécuter B" est étrange. Il serait même plus étrange que l'instruction Asoit une simple affectation, nécessitant du code supplémentaire pour forcer une exception si elle conditionest fausse (et cela nécessiterait probablement de iftoute façon une instruction-).


2

Eh bien, juste une question d’étiquette, avant de "commencer une dispute avec eux", comme vous le dites, je voudrais demander: "Pourquoi utilisent-ils la gestion des exceptions dans tous ces endroits différents?"

Je veux dire, il y a plusieurs possibilités:

  1. ils sont incompétents
  2. ils ont une raison tout à fait valable, qui peut ne pas apparaître à première vue.
  3. Parfois, c'est une question de goût et peut simplifier un flux de programme complexe.
  4. C'est un vestige du passé que personne n'a encore changé et qui serait heureux si quelqu'un le faisait

... Je pense que tout cela est également probable. Alors, demandez-leur gentiment.


1

Try Catch ne doit être utilisé que pour la gestion des exceptions. Plus encore, gestion des exceptions spécifiques. Votre prise d'essai ne devrait capturer que les exceptions attendues, sinon elle n'est pas bien formée. Si vous devez utiliser une attrape tout essayer attraper, alors vous faites probablement quelque chose de mal.

MODIFIER:

Raison: vous pouvez dire que si vous utilisez try catch en tant qu'opérateur conditionnel, comment allez-vous comptabiliser les exceptions REAL?


2
Le PO demande des raisons / arguments. Vous n'en avez fourni aucune.
Oded

"Vous pouvez argumenter que si vous utilisez try catch en tant qu'opérateur conditionnel, comment allez-vous comptabiliser les exceptions REAL?" - en capturant ces exceptions réelles dans une catchclause différente de celle qui vise les exceptions "non réelles"?

@delnan - Merci! vous avez prouvé un point que j'allais dire. Si une personne répondait à ce que vous venez de dire à ma raison et à celle d'Oded, je cesserais de parler parce qu'il ne cherchait pas les raisons pour lesquelles il était juste têtu et que je ne perdais pas mon temps avec l'obstination.
AJC

Vous m'appelez studdborn parce que je signale des failles dans certains des arguments énumérés ici? Notez que je n'ai rien à dire contre les autres points énoncés ici. Je ne suis pas partisan d'utiliser des exceptions pour le contrôle de flux (bien que je ne condamne rien non plus sans détails, d'où ma demande d'élaboration par OP), je ne fais que défendre l'avocat du diable.

1
L'utilisation de try-catch en tant qu'opérateur conditionnel ne l'empêche en aucun cas de capturer des exceptions "réelles".
Winston Ewert

1

Les exceptions sont pour quand chose exceptionnelle se produire. Le programme fonctionne-t-il selon un flux de travail régulier exceptionnel?


1
Mais pourquoi? La question qui se pose est de savoir pourquoi (ou pourquoi pas) les exceptions ne sont que bonnes pour cela.
Winston Ewert

Pas toujours "exceptionnel". Le fait de ne pas trouver de clé dans une table de hachage n’est pas exceptionnel, par exemple, mais la bibliothèque OCaml a tendance à créer une exception dans de tels cas. Et tout va bien - la gestion des exceptions est très bon marché là-bas.
SK-logic le

1
-1: déclaration tautologique
Biscuits à la farine de riz

1

Raison d'utiliser des exceptions:

  1. Si vous oubliez d'attraper une circonstance exceptionnelle, votre programme mourra et la trace de pile vous dira exactement pourquoi. Si vous oubliez de gérer la valeur de retour pour une circonstance d'exception, il est impossible d'indiquer à quelle distance votre programme affichera un comportement incorrect.
  2. L'utilisation des valeurs de retour ne fonctionne que s'il existe une valeur sentinelle que vous pouvez retourner. Si toutes les valeurs de retour possibles sont déjà valides, qu'allez-vous faire?
  3. Une exception contiendra des informations supplémentaires sur ce qui s'est passé, ce qui peut être utile.

Raisons pour ne pas utiliser d'exceptions:

  1. Beaucoup de langues ne sont pas conçues pour faire des exceptions rapidement.
  2. Les exceptions qui parcourent plusieurs couches de la pile peuvent laisser un état incohérent dans leur sillage

À la fin:

L'objectif est d'écrire du code qui communique ce qui se passe. Les exceptions peuvent aider / entraver cela en fonction de ce que fait le code. Un try / catch en python pour une KeyError sur une référence de dictionnaire est parfaitement (tant que vous connaissez la langue) try / catch pour le même KeyError à cinq couches de fonction est dangereux.


0

J'utilise try-> catch comme contrôle de flux dans certaines situations. Si votre logique principale dépend de quelque chose qui échoue, mais que vous ne voulez pas simplement lancer une exception et quitter ... C'est à quoi sert un bloc try-> catch. J'écris beaucoup de scripts unix côté serveur non surveillés, et il est bien plus important pour eux de ne pas échouer que pour qu'ils échouent joliment.

Alors essayez Plan A, et si Plan A meurt, attrapez et exécutez avec Plan B ... Et si Plan B échoue, utilisez enfin pour lancer Plan C, qui corrigera l’un des services défaillants dans A ou B, ou page moi.


0

Cela dépend de la langue et peut-être de la mise en œuvre utilisée. La norme en C ++ est que les exceptions doivent être sauvegardées pour des événements vraiment exceptionnels. En revanche, en Python, l’un des principes est " Il est plus facile de demander pardon que pour obtenir une permission ", de sorte que l’intégration des blocs try / except dans la logique du programme est encouragée.


"La norme en C ++ est que les exceptions doivent être sauvegardées pour des événements vraiment exceptionnels." Ça n'a pas de sens. Même l'inventeur de la langue n'est pas d'accord avec vous .
arayq2

-1

C'est une mauvaise habitude, mais je le fais de temps en temps en python. Comme au lieu de vérifier pour voir si un fichier existe, je viens d'essayer de le supprimer. Si cela jette une exception, j'attrape et passe juste en sachant que ce n'était pas là. <== (pas nécessairement vrai si un autre utilisateur est propriétaire du fichier, mais que je le fais dans le répertoire de base de l'utilisateur, cela ne devrait donc pas se produire).

Pourtant, trop utilisé, c'est une mauvaise pratique.


3
Dans cet exemple, utiliser des exceptions au lieu de "regarder avant de sauter" est en fait une bonne idée: cela évite les conditions de concurrence. Une vérification de la disponibilité du fichier (existence, autorisations, non verrouillé) réussie ne signifie pas une réussite ultérieure - même s’il ne s’agit que de quelques opcodes ultérieurs - l’accès (ouverture, suppression, déplacement, verrouillage, etc.) aboutira, car le fichier pourrait être modifié (supprimé, déplacé, ses autorisations ont été modifiées) entre.

Si python génère une exception simplement parce qu'un fichier n'existe pas, cela semble encourager les mauvaises habitudes, comme le décrit Delnan.
Per Johansson le

@delnan: Bien que vrai, à mon humble avis, si vous rencontrez de telles conditions de concurrence, vous devez repenser votre conception. Dans un tel cas, il existe clairement une séparation insuffisante des problèmes dans vos systèmes. À moins que vous n’ayez de très bonnes raisons d’agir de la sorte, vous devez unifier l’accès de votre côté ou utiliser une base de données appropriée pour gérer plusieurs clients essayant d’effectuer des transactions sur les mêmes données persistantes.
back2dos

1
Ce n'est pas une mauvaise habitude. C'est le style recommandé en Python.
Winston Ewert

@ back2dos, pouvez-vous l'éviter lorsque vous utilisez des ressources externes telles que d'autres utilisateurs de la base de données / du système de fichiers?
Winston Ewert

-1

J'aime la façon dont Apple le définit : les exceptions ne concernent que les erreurs de programmation et les erreurs d'exécution fatales. Sinon, utilisez des codes d'erreur. Cela m'aide à décider quand l'utiliser, pensant à moi-même: "Est-ce une erreur de programmation?"


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.