Il est conseillé d’utiliser try-sauf-sinon en python ?

Question

De temps à autre sur python, je vois le bloc

try:
   try_this(whatever)
except SomeException, exception:
   #Handle exception
else:
   return something

Quelle est la raison pour l'essayer, sauf d'autre pour exister?

Je ne sais pas si c'est de l'ignorance, mais je n'aime pas ce genre de programmation, comme c'est l'utilisation d'exceptions pour effectuer le contrôle de flux.

Toutefois, s'il est inclus dans le langage lui-même, il doit y avoir une bonne raison pour ça, n'est-ce pas?

Il ma compréhension que les exceptions ne sont pas des erreurs, ils ne doivent être utilisés pour des conditions exceptionnelles (ie: j'essaie d'écrire un fichier sur le disque et il n'y a pas plus de place, ou peut-être que je n'ai pas l'autorisation), de ne pas effectuer de contrôle de flux.

Normalement, je gérer les exceptions comme

something = some_default_value
try:
    something = try_this(whatever)
except SomeException, exception:
    #Handle exception
finally:
    return something

d', si j'ai vraiment pas envie de retourner quoi que ce soit si une exception se produit, alors

try:
    something = try_this(whatever)
    return something
except SomeException, exception:
    #Handle exception

Ai-je raté quelque chose?

Answer 1

"Je ne sais pas si c'est de l'ignorance, mais je n'aime pas qu' type de programmation, comme c'est l'utilisation d'exceptions pour effectuer le contrôle de flux."

Dans le Python du monde, à l'aide d'exceptions pour le contrôle de flux est courant et normal.

Même le Python de base aux développeurs d'utiliser les exceptions pour le contrôle du flux et que le style est fortement ancré dans la langue (c'est à dire l'itérateur protocole utilise StopIteration à boucle de signal de terminaison).

En outre, l'essai, à l'exception de style est utilisé pour prévenir la course-conditions inhérentes à certains de la "regardez-avant-vous-saut" constructions. Par exemple, le test de l'os.chemin d'accès.il existe des résultats dans les informations qui peuvent être out-of-date au moment de l'utilisation. De Même, La File D'Attente.plein renvoie des informations qui peuvent être obsolètes. Le try-except-d'autre style de la fiabilité de code dans ces cas.

"Il ma compréhension que les exceptions ne sont pas des erreurs, ils ne doivent être utilisé pour des conditions exceptionnelles"

Dans quelques autres langues, que la règle est le reflet de leurs normes culturelles reflétées dans leurs bibliothèques. La "règle" est également basée en partie sur des considérations de performance pour ces langues.

Le Python norme culturelle est peu différent. Dans de nombreux cas, vous devez utiliser les exceptions pour le contrôle de flux. Aussi, l'utilisation d'exceptions en Python ne pas ralentir les environs de code et de code d'appel comme c'est le cas dans certains langages compilés (c Disponible implémente déjà le code pour l'exception de vérifier à chaque étape, peu importe si vous l'utiliser effectivement des exceptions ou pas).

En d'autres termes, votre compréhension que "les exceptions sont pour les exceptionnels" est une règle qui fait sens dans quelques autres langues, mais pas pour Python.

"Toutefois, s'il est inclus dans le langage lui-même, il doit y avoir un bonne raison pour ça, n'est-ce pas?"

En plus d'aider à éviter la race des conditions, des exceptions sont également très utiles pour tirer de gestion des erreurs à l'extérieur des boucles. C'est un besoin d'optimisation dans les langages qui n'ont pas tendance à avoir automatiquement invariant de boucle de code de mouvement.

Aussi, des exceptions peuvent simplifier le code un peu en commun des situations où la capacité à gérer un problème est loin de l'endroit où le problème se pose. Par exemple, il est courant d'avoir de premier niveau de code d'interface utilisateur code d'appel de la logique d'entreprise qui à son tour appelle les routines de bas niveau. Les Situations qui en découlent dans les routines de bas niveau (tels que les enregistrements en double de clés uniques dans les accès base de données) ne peuvent être traitées que dans le premier niveau de code (par exemple en demandant à l'utilisateur pour une nouvelle clé qui n'entre pas en conflit avec les clés). L'utilisation d'exceptions pour ce type de contrôle de flux permet un niveau moyen de routines d'ignorer complètement le problème et bien découplé de cet aspect de contrôle de flux.

Il y a un joli blog sur la indispensibility des exceptions ici.

Aussi, voir ce StackOverFlow réponse: les exceptions Sont vraiment exceptionnels, des erreurs?

"Quelle est la raison pour l'essayer, sauf autre d'exister?"

Le reste de la clause en elle-même est intéressante. Il s'exécute quand il n'y a pas d'exception, mais, avant enfin de la clause. C'est son but premier.

Sans le bloc else, la seule option pour exécuter du code supplémentaire avant la finalisation serait maladroit de la pratique de l'ajout du code à l'essai, la clause. C'est maladroit car il risque le déclenchement d'exceptions dans le code qui n'était pas destiné à être protégés par la essayez-bloc.

Le cas d'utilisation de l'exécute d'autres non protégés code avant la finalisation n'apparaît pas très souvent. Donc, ne vous attendez pas à voir de nombreux exemples dans code publié. Il est assez rare.

Un autre cas d'utilisation pour le reste de la clause de sauvegarde pour effectuer des actions qui doivent se produire lorsque aucune exception ne se produit et ne se produire lorsque les exceptions sont gérées. Par exemple:

   recip = float('Inf')
   try:
       recip = 1 / f(x)
   except ZeroDivisionError:
       logging.info('Infinite result')
   else:
       logging.info('Finite result')

Enfin, l'usage le plus courant d'une autre personne-la clause de un essayez-le bloc est un peu d'embellissement (en alignant les résultats exceptionnels et non des résultats exceptionnels au même niveau d'indentation). Cette utilisation est toujours facultative et n'est pas strictement nécessaire.

Answer 2

Python ne souscris pas à l'idée que les exceptions doivent être utilisées uniquement pour des cas exceptionnels, en fait, le langage est "demander pardon, sans autorisation". Cela signifie que l'utilisation des exceptions, comme une partie de la routine de votre contrôle de flux est parfaitement acceptable, et en fait, encouragé.

C'est généralement une bonne chose, comme le fait de travailler de cette façon permet d'éviter certains problèmes (comme un exemple évident, les conditions de course sont souvent évités), et il tend à rendre le code un peu plus lisible.

Imaginez que vous avez une situation où vous prenez la saisie de l'utilisateur qui a besoin d'être traitées, mais qui ont un défaut qui est déjà traitée. L' try: ... except: ... else: ... de la structure est très lisible le code:

try:
   raw_value = int(input())
except ValueError:
   value = some_processed_value
else: # no error occured
   value = process_value(raw_value)

Comparer la manière dont il pourrait travailler dans d'autres langues:

raw_value = input()
if valid_number(raw_value):
    value = process_value(int(raw_value))
else:
    value = some_processed_value

Remarque les avantages. Il n'est pas nécessaire de vérifier la valeur est valide et l'analyser séparément, ils sont fait une fois. Le code suit un ordre plus logique, le code principal chemin est le premier, suivi par "si cela ne fonctionne pas, cela".

L'exemple est naturellement un peu artificiel, mais il montre qu'il existe des cas pour cette structure.

Answer 3

Vous devez être prudent sur l’utilisation du bloc finally, comme il n’est pas la même chose qu’en utilisant un bloc else dans l’essai, à l’exception. L’enfin bloc sera exécuté quel que soit le résultat de l’essai sauf.

Comme tout le monde a noté à l’aide du bloc else provoque votre code plus lisible et ne fonctionne que lorsqu’une exception n’est levé

Answer 4

Faire une recherche pour « duck-typing ». Il est considéré comme un moyen très Pythonique de même s’il n’est pas la norme dans d’autres langages de programmation. Duck-typing peut entraîner un code plus lisible et plus fiable que la vérification du type explicitement lorsqu’il est utilisé correctement.

Une mise en garde, c’est qu’il n’est pas bon consered à l’exception de toute erreur. Il est fortement recommandé de sauf Erreurs explicites telles que :

ou