Comment puis-je savoir quelles exceptions peuvent être levées par un appel de méthode ?

Question

Existe-t-il un moyen de savoir (au moment du codage) à quelles exceptions il faut s'attendre lors de l'exécution du code python ?

Je finis par attraper la classe Exception de base dans 90 % des cas, car je ne sais pas quel type d'exception peut être déclenché (la lecture de la documentation ne m'aide pas toujours, car une exception peut souvent être propagée à partir de la profondeur). Et souvent, la documentation n'est pas mise à jour ou correcte).

Existe-t-il un outil permettant de vérifier cela (par exemple en lisant le code et les librairies Python) ?

Answer 1

Vous ne devez attraper que les exceptions que vous allez gérer.

Attraper toutes les exceptions par leurs types concrets est un non-sens. Vous devriez attraper les exceptions spécifiques que vous puede y sera poignée. Pour d'autres exceptions, vous pouvez écrire un catch générique qui attrape l'"exception de base", l'enregistre (en utilisant l'option str() ) et termine votre programme (ou fait quelque chose d'autre qui est approprié dans une situation de crash).

Si tu veux vraiment gérer tous et que vous êtes sûr qu'aucune d'entre elles n'est fatale (par exemple, si vous exécutez le code dans une sorte d'environnement sandbox), votre approche consistant à attraper les BaseException génériques correspond à vos objectifs.

Vous pourriez également être intéressé par référence d'exception linguistique et non une référence pour la bibliothèque que vous utilisez.

Si la référence de la bibliothèque est vraiment mauvaise et qu'elle ne relance pas ses propres exceptions lorsqu'elle attrape celles du système, la seule approche utile est d'exécuter des tests (peut-être l'ajouter à la suite de tests, car si quelque chose n'est pas documenté, cela peut changer !) Supprimez un fichier crucial pour votre code et vérifiez quelle exception est levée. Fournissez trop de données et vérifiez quelle erreur cela produit.

Vous devrez de toute façon effectuer des tests, puisque, même si la méthode permettant d'obtenir les exceptions par le code source existait, elle ne vous donnerait aucune idée de la manière dont vous devez traiter ces exceptions. . Peut-être devriez-vous afficher le message d'erreur "Le fichier needful.txt n'est pas trouvé !" lorsque vous attrapez IndexError ? Seul le test peut le dire.

Answer 2

Je suppose qu'une solution ne pourrait être qu'imprécise en raison de l'absence de règles de typage statique.

Je ne connais pas d'outil qui vérifie les exceptions, mais vous pourriez créer votre propre outil en fonction de vos besoins (une bonne occasion de jouer un peu avec l'analyse statique).

Comme première tentative, vous pourriez écrire une fonction qui construit un AST, trouve tous les éléments de l'AST. Raise et essaie ensuite de déterminer les modèles courants de levée d'exceptions (par exemple, l'appel direct d'un constructeur).

Soit x soit le programme suivant :

x = '''\
if f(x):
    raise IOError(errno.ENOENT, 'not found')
else:
    e = g(x)
    raise e
'''

Construire l'AST en utilisant le compiler paquet :

tree = compiler.parse(x)

Définissez alors une Raise classe de visiteurs :

class RaiseVisitor(object):
    def __init__(self):
        self.nodes = []
    def visitRaise(self, n):
        self.nodes.append(n)

Et marcher sur l'AST en collectant Raise des nœuds :

v = RaiseVisitor()
compiler.walk(tree, v)

>>> print v.nodes
[
    Raise(
        CallFunc(
            Name('IOError'),
            [Getattr(Name('errno'), 'ENOENT'), Const('not found')],
            None, None),
        None, None),
    Raise(Name('e'), None, None),
]

Vous pouvez continuer en résolvant les symboles en utilisant les tables de symboles du compilateur, en analysant les dépendances de données, etc. Ou vous pouvez simplement déduire que CallFunc(Name('IOError'), ...) "devrait définitivement signifier l'augmentation IOError ", ce qui est tout à fait correct pour des résultats pratiques rapides :)

Answer 3

L'outil correct pour résoudre ce problème est unittests. Si vous avez des exceptions soulevées par du code réel que les unittests ne soulèvent pas, alors vous avez besoin de plus de unittests.

Considérez ceci

def f(duck):
    try:
        duck.quack()
    except ??? could be anything

le canard peut être n'importe quel objet

Il est évident que vous pouvez avoir un AttributeError si le canard ne fait pas coin-coin, un TypeError si le canard a un coin-coin mais il n'est pas appelable. Vous n'avez aucune idée de ce que duck.quack() pourrait cependant soulever, peut-être même un DuckError ou quelque chose comme ça

Supposons maintenant que vous ayez un code comme celui-ci

arr[i] = get_something_from_database()

Si elle soulève un IndexError vous ne savez pas si elle provient de arr[i] ou de l'intérieur de la fonction de base de données. en général, l'endroit où l'exception s'est produite n'est pas très important, mais plutôt le fait que quelque chose s'est mal passé et que ce que vous vouliez ne s'est pas produit.

Une technique pratique est d'attraper et peut-être de relancer l'exception comme ceci

except Exception as e
    #inspect e, decide what to do
    raise

Answer 4

Personne n'a expliqué jusqu'à présent pourquoi il n'est pas possible d'avoir une liste d'exceptions complète et 100% correcte, alors j'ai pensé que cela valait la peine d'être commenté. L'une des raisons est une fonction de première classe. Disons que vous avez une fonction comme celle-ci :

def apl(f,arg):
   return f(arg)

Maintenant apl peut soulever toute exception que f soulève. Bien qu'il n'y ait pas beaucoup de fonctions de ce type dans la bibliothèque principale, tout ce qui utilise la compréhension de liste avec des filtres personnalisés, map, reduce, etc. est affecté.

La documentation et les analyseurs de sources sont les seules sources "sérieuses" d'information ici. Gardez à l'esprit ce qu'ils ne peuvent pas faire.

Answer 5

J'ai rencontré ce problème lors de l'utilisation de socket, je voulais trouver toutes les conditions d'erreur auxquelles je pouvais être confronté (donc plutôt que d'essayer de créer des erreurs et de comprendre ce que fait socket, je voulais juste une liste concise). Finalement, j'ai fini par rechercher "raise" dans "/usr/lib64/python2.4/test/test_socket.py" :

$ grep raise test_socket.py
Any exceptions raised by the clients during their tests
        raise TypeError, "test_func must be a callable function"
    raise NotImplementedError, "clientSetUp must be implemented."
    def raise_error(*args, **kwargs):
        raise socket.error
    def raise_herror(*args, **kwargs):
        raise socket.herror
    def raise_gaierror(*args, **kwargs):
        raise socket.gaierror
    self.failUnlessRaises(socket.error, raise_error,
    self.failUnlessRaises(socket.error, raise_herror,
    self.failUnlessRaises(socket.error, raise_gaierror,
        raise socket.error
    # Check that setting it to an invalid value raises ValueError
    # Check that setting it to an invalid type raises TypeError
    def raise_timeout(*args, **kwargs):
    self.failUnlessRaises(socket.timeout, raise_timeout,
    def raise_timeout(*args, **kwargs):
    self.failUnlessRaises(socket.timeout, raise_timeout,

Ce qui est une liste d'erreurs assez concise. Bien sûr, cela ne fonctionne qu'au cas par cas et dépend de l'exactitude des tests (ce qui est généralement le cas). Sinon, il faut attraper toutes les exceptions, les enregistrer, les disséquer et trouver comment les gérer (ce qui n'est pas si difficile avec les tests unitaires).