Je dois identifier qui soulevez une exception pour gérer une mauvaise erreur STR, existe-t-il un moyen?
Regardez mon exemple: P>
try:
os.mkdir('/valid_created_dir')
os.listdir('/invalid_path')
except OSError, msg:
# here i want i way to identify who raise the exception
if is_mkdir_who_raise_an_exception:
do some things
if is_listdir_who_raise_an_exception:
do other things ..
4 Réponses :
envelopper dans "Essayez / attraper" chaque fonction individuellement. Cela aidera de toute façon lisibilité / compréhension.
Selon les détails, le deuxième essayez ... sauf pourrait éventuellement aller dans un else: bloc de la première.
Ceci modifie légèrement la logique - si le mkdir échoue car le répertoire existe déjà, il est nécessaire de faire le listDir peu importe.
Bien sûr, je n'ai pas fabriqué toute la solution, juste le principe.
Que diriez-vous de la solution simple:
try:
os.mkdir('/valid_created_dir')
except OSError, msg:
# it_is_mkdir_whow_raise_ane_xception:
do some things
try:
os.listdir('/invalid_path')
except OSError, msg:
# it_is_listdir_who_raise_ane_xception:
do other things ..
Si vous avez des tâches complètement séparées pour exécuter en fonction de quelle fonction a échoué, car votre code semble afficher, alors les blocs try / exécutés distincts, comme les réponses existantes suggèrent, peut être meilleure (bien que vous puissiez probablement pas besoin de sauter la seconde partie si le premier a échoué).
Si vous avez beaucoup de choses que vous devez faire dans les deux cas, et seulement un peu de travail qui dépend de quelle fonction a échoué, puis la séparation peut créer beaucoup de doubles emplois et de répétition Donc, la forme que vous avez suggérée peut bien être préférable. Traceback Module de la bibliothèque standard de Python peut aider dans cette cas: bien sûr au lieu du Imprimer Vous utiliserez si vérifie exactement quel traitement .
@LUC, ce serait la source mais seulement si disponible; Citant les docs à docs.python.org/library/... < / a>, "" "Une" entrée de trace de pile "pré-traitée" est un quadruple (nom de fichier, numéro de ligne, nom de fonction, texte) représentant les informations généralement imprimées pour une trace de pile. le Le texte est une chaîne avec des espaces blancheurs de tête et de fuite. Si la source n'est pas disponible, il n'en est pas. "" "Comme vous le voyez Function_Name est à l'index 2 dans le tuple.
L'essai / sauf, essayez / sauf la solution peut être meilleur, mais dans mon cas, je dois gérer, quelle fonction augmente l'exception, de sorte que cette réponse est la meilleure pour moi! Merci :)
@boos: Comment utiliser deux essais / sauf les blocs ne vous indique pas quelle fonction a soulevé l'exception?
@Tom: Bien sûr! En utilisant deux essais / à l'exception du bloc, dites-moi quelle fonction a soulevé l'exception, mais ce n'est pas ce que je veux. Jetez un coup d'œil au code que j'écris après la réponse @Alex Martelli Nopaste.voric.com /paste.php?f=4nhemg
@TOM: Je pense que le premier code est le mode lisible que celui-ci: Nopaste.voric.com /paste.php?f=gpiPbi
Si vous avez un comportement légèrement différent pour les exceptions à différents endroits, vous devriez être Nibling Les gestionnaires d'exception, et non la ramification basée sur des traces de pile.
@Glenn Maynard: quelque chose comme ça? Je n'aime pas ça nopaste.voric.com/past.php?f=s53vtv "/a >
@Alexmartelli the extray_tb appel ici ne me semble pas, cela donne le cadre le plus haut dans la pile, plutôt que le plus profond de l'exception, ou le niveau suivant où nous avons Accès au nom de la fonction appelée. Pour que cela fonctionne comme prévu, je devais utiliser stk = traceback.extract_tb (tb, 2); fname = stk [-1] [2] à la place.
Voici l'approche propre: joignez des informations supplémentaires à l'exception où elle se produit, puis l'utilise dans un endroit unifié: dans la pratique, vous souhaiteriez créer des emballages pour des fonctions comme Mkdir et ListDir si vous voulez faire cela, plutôt que de disperser un petit essai à l'exception de votre code sur votre code. Normalement, je ne trouve pas ce niveau de détail dans des messages d'erreur si importants (le python Le message est généralement beaucoup), mais c'est un moyen propre de le faire.