“Demander pardon de ne pas l'autorisation” - expliquer

Je ne demande pas à des fins personnelles "religieux" avis au sujet de cette philosophie, plutôt quelque chose d'un peu plus de technique.

Je comprends cette phrase est l'un de plusieurs de tournesol tests pour voir si votre code est "pythonic". Mais pour moi, pythonic signifie propre, simple et intuitive, pas chargé avec des gestionnaires d'exception pour les mauvais codage.

Donc, à l'exemple pratique. Je définir une classe:

class foo(object):
    bar = None

    def __init__(self):
        # a million lines of code
        self.bar = "Spike is my favorite vampire."
        # a million more lines of code

Maintenant, venir à partir d'un contexte procédural, dans une autre fonction que je veux faire ceci:

if foo.bar:
    # do stuff

Je vais obtenir un attribut exception si j'étais impatient et n'a pas faire les premiers foo = None. Donc, "demander pardon de ne pas l'autorisation" donne à penser que je devrais faire à la place?

try:
    if foo.bar:
        # do stuff
except:
    # this runs because my other code was sloppy?

Pourquoi il serait mieux pour moi d'ajouter une logique supplémentaire dans un bloc try juste pour que je puisse laisser ma définition de la classe plus ambigu? Pourquoi ne pas définir tout d'abord, donc explicitement accorder l'autorisation?

(Ne me battre sur l'utilisation de blocs try/except... je l'utilise partout. Je ne pense pas qu'il est juste de les utiliser pour attraper mes propres erreurs car je n'ai pas approfondi programmeur.)

Ou... dois-je totalement méconnaître le "Demander Forgivess" mantra?

Votre déclaration "n'est pas chargé avec des gestionnaires d'exception pour les mauvais codage" est un non sequitur. Bon code a tous à l'exception de la manipulation nécessaire, mais pas un peu plus. Et la présence de gestionnaires d'exceptions à peine implique de "mauvais codage." Je pense que sa serait préférable de laisser l'application gérer un problème si possible (si pour aucune autre raison que de fermer gracieusement), plutôt que de permettre qu'il se bloque sans ménagement dans les genoux de l'utilisateur 🙂
Vous ne devriez pas essayer d'ajouter des gestionnaires d'exception pour attraper les mauvais codage, et surtout pas un nu except: clause. Vos tests unitaires doivent attraper ces problèmes, et il n'y a rien de mal avec l'exception de cracher une traçabilité en amont et en tuant l'ensemble du processus pour ce genre d'erreur.
Un autre avantage de demander pardon, c'est qu'il peut parfois éviter des bugs que l'autorisation ne peut tout simplement pas, lorsque vous faites affaire avec de dynamique hors de votre contrôle. Je pense que l'exemple canonique est os.path.exists, qui vous indique seulement que le fichier existe ou n'existe pas, à un certain point. Probablement 90%+ de if os.path.exists(filename): do_something_to(filename) les usages sont techniquement buggy.
ou tout simplement open() - ne pas vérifier pour voir si vous pouvez ouvrir le fichier en premier (autorisations, à l'existence, etc...) - il suffit de l'essayer 🙂 [qui évite des conditions de course]

InformationsquelleAutor hikaru | 2012-09-04

python

56

Le classique "demander pardon de ne pas l'autorisation" exemple est l'accès à des valeurs à partir d'un dict qui peut ne pas exister. E. g.:
```
names = { 'joe': 'Joe Nathan', 'jo': 'Jo Mama', 'joy': 'Joy Full' }
name = 'hikaru'

try:
    print names[name]
except KeyError:
    print "Sorry, don't know this '{}' person".format(name)
```
Ici l'exception qui pourrait se produire (KeyError) est indiqué, de sorte que vous n'êtes pas à demander pardon pour toutes les erreurs qui peuvent se produire, mais seulement celui qui se produisent naturellement.
Pour comparaison, le "demander la permission d'abord" pourrait ressembler à:
```
if name in names:
    print names[name]
else:
    print "Sorry, don't know this '{}' person".format(name)
```
ou
```
real_name = names.get(name, None)
if real_name:
    print real_name
else:
    print "Sorry, don't know this '{}' person".format(name)
```
De tels exemples de "demander pardon" sont souvent trop simples. IMO c'est pas limpide que try/except blocs sont intrinsèquement meilleure que if/else. La valeur réelle est beaucoup plus claire lors de l'exécution d'opérations qui peuvent échouer dans une variété de moyens, tels que l'analyse; à l'aide de eval(), l'accès au système d'exploitation, middleware, base de données, ou de ressources en réseau, ou en effectuant des mathématiques complexes. Lorsqu'il y a plusieurs modes de défaillance potentiels, être prêt à obtenir le pardon est très précieuse.

D'autres notes au sujet de vos exemples de code:

Vous n'avez pas besoin de louche try/except les blocs autour de chaque variable d'utilisation. Ce serait horrible. Et vous n'avez pas besoin de self.bar dans votre __init__() depuis qu'il est défini dans votre class définition ci-dessus. Il est habituel de définir dans la classe (si c'est des données susceptibles d'être partagée entre toutes les instances de la classe) ou dans le __init__() (si c'est des données d'instance, spécifiques à chaque instance).

Une valeur de None n'est pas défini, ou une erreur, par la manière. C'est un spécifique et légitime la valeur, le sens aucun, nul, nul, ou rien. Beaucoup de langues ont de telles valeurs, les programmeurs ne pas "surcharger" 0, -1, '' (chaîne vide) ou similaire valeurs utiles.
- Tout le monde a eu d'excellents commentaires. J'ai marqué ceci comme la réponse, car elle précise deux choses pour moi: "Il est habituel de définir dans la classe (si c'est des données susceptibles d'être partagée entre toutes les instances de la classe) ou dans le __init__() (si c'est des données d'instance, spécifiques à chaque instance)." est un rappel nécessaire pour moi de la façon dont les choses fonctionnent dans la programmation orientée-objet, et "Lorsqu'il y a plusieurs modes de défaillance potentiels, être prêt à obtenir le pardon est très précieuse." Merci à tous pour les bonnes réponses, et désolé pour mon mauvais exemples.
InformationsquelleAutor Jonathan Eunice
59

“Demander pardon, pas la permission” oppose deux styles de programmation. “Demander l'autorisation” va comme ceci:
```
if can_do_operation():
    perform_operation()
else:
    handle_error_case()
```
“Demander pardon” va comme ceci:
```
try:
    perform_operation()
except Unable_to_perform:
    handle_error_case()
```
C'est une situation où il est prévu que d'essayer d'effectuer l'opération peut échouer, et vous avez à gérer la situation où l'opération est impossible, d'une manière ou d'une autre. Par exemple, si l'opération est de l'accès à un fichier, le fichier peut ne pas exister.

Il y a deux raisons principales pour lesquelles il est préférable de demander pardon:
- Dans un concurrrent monde (dans un programme multithread, ou si l'opération implique des objets qui sont externes au programme, telles que des fichiers, d'autres processus, les ressources du réseau, etc.), la situation peut changer entre le moment où vous exécutez can_do_operation() et le temps lorsque vous exécutez perform_operation(). Donc, vous avez à gérer l'erreur de toute façon.
- Vous avez besoin d'utiliser exactement les bons critères pour en demander la permission. Si vous l'obtenez incorrecte, vous allez être dans l'impossibilité d'effectuer une opération que vous pouvez effectuer, ou une erreur de se produire parce que vous ne pouvez pas effectuer l'opération, après tout. Par exemple, si vous tester si un fichier existe avant de l'ouvrir, il est possible que le fichier n'existe pas, mais vous ne pouvez pas l'ouvrir parce que vous n'avez pas la permission. À l'inverse, peut-être que le fichier est créé lorsque vous l'ouvrez (par exemple parce qu'il s'agit d'une connexion réseau qui est seulement quand il vous fait ouvrir le fichier, pas quand vous piquez-les pour voir si elle est là).
Ce demander pardon situations ont en commun, c'est que vous tentez d'effectuer une opération, et vous savez que l'opération peut échouer.

Lorsque vous écrivez foo.bar, la non-existence de bar n'est pas normalement considéré comme un échec de l'objet foo. C'est habituellement un programmeur d'erreur: tentative d'utilisation d'un objet de façon qu'il n'a pas été conçu pour. La conséquence d'une erreur du développeur Python est un non gérée exception (si vous avez de la chance: bien sûr, certaines erreurs du développeur ne peut pas être détecté automatiquement). Donc, si bar est un élément facultatif de l'objet, la manière habituelle de traiter cette question est d'avoir une bar champ est initialisé à None, et une autre valeur si l'option est présente. Pour tester si bar est présent, écrire
```
if foo.bar is not None:
     handle_optional_part(foo.bar)
else:
     default_handling()
```
Vous pouvez abréger if foo.bar is not None: à if foo.bar: seulement si bar sera toujours vrai que si elle est interprétée comme une valeur de type boolean — si bar pourrait être 0, [], {} ou tout autre objet qui a une fausse valeur de vérité, vous avez besoin de la is not None. Il est également plus clair, si vous faites des tests pour une partie facultative (par opposition à des tests entre True et False).

À ce stade, vous vous demandez peut-être pourquoi ne pas omettre l'initialisation de bar quand il n'y est pas, et de tester sa présence avec hasattr ou de l'attraper avec une AttributeError gestionnaire? Parce que votre code n'a de sens que dans deux cas:
- l'objet n'a pas bar champ;
- l'objet a une bar champ, cela signifie que ce que vous pensez que cela signifie.
Donc, lors de l'écriture ou de décider de l'utilisation de l'objet, vous devez vous assurer que ce n'est pas un bar de terrain avec un sens différent. Si vous devez utiliser un autre objet qui n'a pas de bar champ, ce n'est probablement pas la seule chose que vous aurez besoin de s'adapter, de sorte que vous aurez probablement envie de faire une classe dérivée ou d'encapsuler l'objet dans un autre.
- Gilles puis-je poser une question latérale qui n'est pas pertinent pour la question elle-même, mais plus avec la philosophie? Pourquoi cette question a été marquée comme non-constructif? Il était réellement très constructif (au moins pour moi) cause il dispose de 2 grandes réponses comme la vôtre et jonathan. Merci
- href="http://meta.stackoverflow.com/questions/276485/why-was-the-question-ask-forgiveness-not-permission-explain-closed-as-non">me Bat (et concernant la philosophie, la bonne chose à faire dans cette situation serait de demander sur meta).
- Enfin, après plus d'une décennie d'écrire du code Python, j'ai trouvé une bonne raison pour l'aeap—deux, en fait! Merci!!!! Je suis surpris et attristé que je n'ai pas lu ce raisonnement python.org. Malheureusement, python.org aussi a fait un mauvais travail à décourager les gens d'écrire général except clauses, et j'ai eu à traiter avec des scores de difficile-à-trouver des bugs comme un résultat. De toute façon, je pense que c'est la meilleure réponse.
InformationsquelleAutor Gilles 'SO- stop being evil'
7

Vous avez le droit-le but de try et except ne sont pas à couvrir votre bâclée de codage. Qui mène juste à la plus bâclée de codage.

La gestion des exceptions devraient être utilisés pour gérer des circonstances exceptionnelles (bâclée de codage n'est pas une circonstance exceptionnelle). Cependant, souvent, il est facile de prédire que des circonstances exceptionnelles peuvent se produire. (par exemple, un votre programme accepte des entrées de l'utilisateur et l'utilise pour accéder à un dictionnaire, mais l'entrée de l'utilisateur n'était pas une clé dans le dictionnaire ...)

InformationsquelleAutor mgilson
7

Il ya beaucoup de bonnes réponses ici, j'ai juste pensé que je voudrais ajouter un point que je n'ai pas vu mentionnée.

Souvent à demander pardon au lieu de la permission a des améliorations de performances.
- Lorsque vous demandez l'autorisation, vous devez effectuer une opération supplémentaire
  pour demander la permission chaque temps.
- Lors de la demande de pardon,
  vous n'avez qu'à effectuer une opération supplémentaire parfois, c'est à dire quand
  il échoue.
Habituellement, les cas sont rares, ce qui signifie que si vous êtes seulement en lui demandant la permission, alors vous avez à peine jamais avoir à faire n'importe des opérations supplémentaires.
Oui, lorsqu'elle échoue, elle renvoie une exception, ainsi que l'exécution d'une opération supplémentaire, mais des exceptions en python sont très rapides. Vous pouvez voir quelques timings ici: https://jeffknupp.com/blog/2013/02/06/write-cleaner-python-use-exceptions/
- Y aurait-il pas des cas où la demande la permission est l'option à privilégier si le taux d'échec est élevé assez bien? Dans la plupart des cas (et de la plupart des langues) ayant pour intercepter une exception est beaucoup de beaucoup de fois plus lent que l'exécution d'une vérification, donc sûrement ce qui fait qu'il est préférable de demander l'autorisation si les circonstances exceptionnelles sont relativement fréquentes, et l'autorisation de test est rapide, non?
- Assurez-vous que le test n'est pas gratuit et la gestion des exceptions n'est pas libre. La gestion des exceptions est contrairement à de nombreuses autres langues moins cher. Si vous avez un test rapide et une très grande proportion des cas où le test échoue, alors vous pouvez les trouver en utilisant le test sera plus rapide. Dans un tel cas, en utilisant le python module timeit peut vous aider à comparer les différentes approches afin de voir laquelle est la plus optimale.
- Voir aussi toutes les autres commentaires sur les avantages fonctionnels de l'utilisation d'exceptions pour éviter les conditions de course, plutôt que de la performance.
InformationsquelleAutor Jonathan Wylie
5

Mon personnel et non-religieux de l'opinion, c'est que dit le mantra s'applique principalement aux documenté et bien compris conditions de sortie et les cas limites (par exemple, erreurs d'e/S), et ne devrait jamais être utilisé comme un get-out-of-prison de la carte pour mauvaise programmation.

Cela dit, try/except est souvent utilisé lorsque le "mieux" que des alternatives existent. Par exemple:
```
# Do this    
value = my_dict.get("key", None)

# instead of this
try:
  value = my_dict["key"]
except KeyError:
  value = None
```
Comme pour ton exemple, n'utilisez if hasattr(foo, "bar") si vos n'avez aucun contrôle sur foo et de la nécessité de vérifier la conformité avec vos attentes, sinon utilisez simplement foo.bar et de laisser l'erreur qui en résulte être votre guide pour l'identification et la résolution bâclée code.

InformationsquelleAutor Shawn Chin
4

Dans le Python contexte de "Demander pardon de ne pas l'autorisation" implique un style de programmation où vous ne vérifiez pas les choses comme vous vous attendez préalablement, mais plutôt de vous traiter les erreurs que si elles ne le sont pas. L'exemple classique est de ne pas vérifier qu'un dictionnaire contient une clé donnée, comme dans:
```
d = {}
k = "k"
if k in d.keys():
  print d[k]
else:
  print "key \"" + k + "\" missing"
```
Mais plutôt de gérer l'erreur qui en résulte si la clé est manquante:
```
d = {}
k = "k"
try:
  print d[k]
except KeyError:
  print "key \"" + k + "\" missing"
```
Toutefois, le point n'est pas de remplacer tous les if dans votre code avec un try/except; ce serait faire de votre code décidément messier. Au lieu de cela, vous ne devez attraper les erreurs où vous pouvez vraiment faire quelque chose à leur sujet. Dans l'idéal, ce serait de réduire le montant de l'ensemble de la gestion des erreurs dans votre code, ce qui rend son objectif réel de plus en plus évidente.

InformationsquelleAutor Nicola Musatti
4

Alors qu'il y a déjà un certain nombre de haute qualité des réponses, plus principalement en discuter à partir d'un point de vue stylistique, comme apposer à une fonctionnelle.

Il y a certains cas où nous avons besoin de demander pardon, pas la permission d'assurer le code est correct (en dehors de programmes multithread).

Un exemple canonique étant,
```
if file_exists: 
    open_it()
```
Dans cet exemple, le fichier peut avoir été supprimé entre la case et en essayant d'ouvrir le fichier. C'est évitée en utilisant try:
```
try:
    open_it()
except FileNotFoundException:
    pass # file doesn't exist 
```
Cette culture dans une variété de lieux, souvent en collaboration avec des systèmes de fichiers ou les Api externe.
- Ce point est important. Ne pense pas à Demander Pardon (AFF) comme un problème du style. Il existe de nombreux cas où Demander la Permission (AFP) est fonctionnellement mal, comme pour les conditions de course que @nick dit ci-dessus. Dire que d'une manière différente: il y a des cas où, si vous utilisez de l'AFP, vous finirez par avoir à gérer les exceptions de toute façon, depuis la pré-condition-vous vérifié peuvent ne pas toujours être le cas lorsque vous exécutez la ligne suivante. Vous avez à gérer l'exception de toute façon, de sorte que vous pourriez aussi bien utiliser de l'AFF en premier lieu. Et de ne pas conduire vous-même fou d'analyser si il pourrait y avoir une condition de concurrence ou pas, il suffit d'utiliser AFF.
InformationsquelleAutor nick
1

Demander pardon de ne pas l'autorisation est destinée à simplifier le code. Il est destiné pour le code à écrire comme ça quand il y a une attente raisonnable que .bar pourrait déclencher une AttributeError.
```
 try:
     print foo.bar
 except AttributeError as e
     print "No Foo!" 
```
Votre code apparaît à la fois demander la permission ET le pardon 🙂

La chose est, si vous pouvez raisonnablement s'attendre à quelque chose à l'échec, utiliser un try/catch. Si vous n'avez pas s'attendre à quelque chose à l'échec, et il échoue, en tout cas, bien l'exception qui obtient jeté devient l'équivalent d'un échec d'assertion dans d'autres langues. Vous voyez où l'exception inattendue est survenue et d'ajuster votre code/hypothèses en conséquence.
- nu except énoncés sont généralement considéré comme une mauvaise pratique. Seul hic, les exceptions que vous savez comment le gérer et rien de plus.
- Je suis d'accord, je viens de copier-coller le OPs code. Ajout d'une capture pour AttributeError
- Plus important que la simplification du code, à mon avis, est que l'AFNP évite la condition de la course inhérents à demander la permission. C'est, lors de la demande d'autorisation, l'état peut changer de "réussira" pour "ne pas réussir" après elle est cochée, mais avant l'opération est effectuée. Si ce n'est pas un problème dans tous les cas d'utilisation, de demander d'autorisation devrait soulever un drapeau rouge pour quelqu'un examen de code, et le drapeau rouge peut être évité en faisant AFNP une pratique constante. @Gilles 's réponse va dans impressionnant de détails à ce sujet.
InformationsquelleAutor Doug T.

Vous devez vous connecter pour publier un commentaire.