comment gérer les exceptions lors de l'écriture d'une bibliothèque en python
Envisagez d'écrire une petite bibliothèque en python qui a cette méthode simple x
qui accepte un argument ac
et renvoie la valeur calculée 10/ac
. maintenant la capture ici est ac
ne peut pas être 0
. alors comment puis-je gérer ce cas dans ma méthode. Il y a ces façons qui me viennent à l'esprit.
REMARQUE: j'ai examiné la gestion des exceptions python, mais cela montre simplement commenttry except
ne pasutiliserle problème spécifique que je pose.
méthode 1
def x(ac):
try:
return (10/ac)
except ZeroDivisionError:
raise ZeroDivisionError("ac cannot be zero")
Le code ci-dessus utilise simplement un bloc try except simple pour intercepter des exceptions spécifiques et lève l'exception au code appelant. donc le code d'appel ressemblerait à ceci :
# some script...
try:
x(0)
except ZeroDivisionError as e:
log(e)
mais dans ce cas, je devrais savoir à l'avance quelles sont toutes les exceptions possibles que cette méthode x
pourrait soulever.
Méthode 2 :
def x(ac):
if ac == 0:
raise ValueError("ac cannot be zero") # or ZeroDivisionError??
else:
return (10/ac)
Je suppose que c'est sémantiquement le même que le précédent, sauf que pour vérifier certaines conditions (dont nous savons qu'elles pourraient se produire) en utilisant if's
et en levant des exceptions en fonction de cela. Elle souffre également du même problème de savoir à l'avance quelles exceptions la méthode peut lever.
méthode 3
La dernière méthode ne gère aucune exception dans la méthode de la bibliothèque plutôt que de la laisser au code client, mais cela n'a évidemment pas de sens car le client ne pourra jamais savoir exactement pourquoi l'erreur peut se produire en recourant à quelque chose comme
def x(ac):
return (10/ac)
try:
x(20)
except Exception as e:
log(e)
maintenant, cette méthode ici était une méthode simple avec une seule opération, mais que se passe-t-il si la méthode elle-même fait quelque chose de compliqué comme se connecter à la base de données puis récupérer des résultats. quelque chose comme :
def x(db):
conn = db.connect('localhost')
results = connec.fetch(user_id=2)
return results
si quelque chose n'est pas clair s'il vous plaît faites le moi savoir.
Cela dépend . Les exceptions comme TypeError
ou ValueError
sont standard et indiquent généralement des erreurs de programmation. Il n'est généralement pas nécessaire d'être explicite à ce sujet.
Le reste, vous documentez . En tant qu'auteur d'API, il est de votre responsabilité d'indiquer clairement quel comportement un autre développeur peut attendre de votre code. Si ZeroDivisionError
c'est un bon signal à documenter, ajoutez-le à la docstring de l'API. À ce stade, il n'est pas non plus nécessaire de l'attraper et de le relancer explicitement. Ne comptez pas sur les utilisateurs qui lisent votre code, donnez-leur plutôt une bonne documentation.
Pour de nombreuses API, il est logique de définir vos propres exceptions. L'implémentation peut intercepter les exceptions génériques ou les exceptions personnalisées des API tierces qu'elle utilise pour effectuer le travail, puis générer une exception spécifique à l'API pour signaler à l'appelant que quelque chose ne va pas, lui permettant de gérer le problème.
Il existe de nombreux exemples de bibliothèques Python populaires avec de telles exceptions. Quelques exemples:
- La
requests
bibliothèque définit des exceptions personnalisées qui sont généralement levées en réponse à d'autres exceptions interceptées , dont beaucoup proviennent d'autres API sousrequests
- jacentes , telles queurllib3
- Werkzeug, une bibliothèque utile pour créer une pile WSGI (applications Web), définit les exceptions HTTP , que les utilisateurs en amont tels que Flask peuvent intercepter et gérer .
- La boîte à outils d'analyse de données Pandas définit plusieurs exceptions et avertissements personnalisés , qui sont utilisés pour indiquer des problèmes tels que l'analyse d'entrée CSV , déclenchée par des exceptions tierces .
- Oreillers, une bibliothèque d'images documente lorsqu'une norme
EOFError
est élevée là où cela est pertinent.
Ce que ces projets ont en commun, c'est une bonne documentation , qui nomme explicitement les exceptions que toute personne utilisant le projet doit connaître.