Comment imprimer le plein de sperme sans arrêter le programme?

Une autre réponse ont déjà souligné le traceback module.

Veuillez noter qu'avec print_exc, dans certains cas du coin, vous ne serez pas obtenir ce que vous attendez. En Python 2.x:

import traceback

try:
    raise TypeError("Oups!")
except Exception, err:
    try:
        raise TypeError("Again !?!")
    except:
        pass

    traceback.print_exc()

...affiche la traçabilité en amont de la dernier exception:

Traceback (most recent call last):
  File "e.py", line 7, in <module>
    raise TypeError("Again !?!")
TypeError: Again !?!

Si vous avez vraiment besoin d'accéder à l'original traceback une solution consiste à mettre en cache les exception d'infos retourné à partir de exc_info dans une variable et de l'afficher à l'aide de print_exception:

import traceback
import sys

try:
    raise TypeError("Oups!")
except Exception, err:
    try:
        exc_info = sys.exc_info()

        # do you usefull stuff here
        # (potentially raising an exception)
        try:
            raise TypeError("Again !?!")
        except:
            pass
        # end of useful stuff


    finally:
        # Display the *original* exception
        traceback.print_exception(*exc_info)
        del exc_info

Production:

Traceback (most recent call last):
  File "t.py", line 6, in <module>
    raise TypeError("Oups!")
TypeError: Oups!

Quelques pièges à cela:

• De la doc de sys_info:

  De l'affectation de la traçabilité en amont de la valeur de retour d'une variable locale dans une fonction qui est de la gestion d'une exception sera la cause d'une référence circulaire. Cela permettra d'empêcher quoi que ce soit référencé par une variable locale dans la même fonction ou par le traceback d'être nettoyée. [...] Si vous avez besoin de la traçabilité en amont, assurez-vous de le supprimer après l'utilisation (de préférence avec une instruction try ... finally)

• mais, à partir de la même doc:

  Début avec Python 2.2, ces cycles sont automatiquement récupéré lors de la collecte des ordures est activé et qu'ils deviennent inaccessibles, mais il reste bien plus efficace pour éviter la création de cycles.

D'autre part, en vous permettant d'accéder à la traçabilité en amont associés à une exception, Python 3 produire moins un résultat surprenant:

import traceback

try:
    raise TypeError("Oups!")
except Exception as err:
    try:
        raise TypeError("Again !?!")
    except:
        pass

    traceback.print_tb(err.__traceback__)

... afficher:

  File "e3.py", line 4, in <module>
    raise TypeError("Oups!")

Si vous êtes le débogage et vous voulez juste pour voir la trace de la pile, vous pouvez simplement appeler:

traceback.print_stack()

Il n'y a pas besoin d'augmenter manuellement une exception juste pour l'attraper à nouveau.

Tout d'abord, ne pas utiliser prints pour l'enregistrement, il est astable, prouvée et bien pensé stdlib module pour faire ça: journalisation. Vous avez certainement devrait l'utiliser à la place.

Deuxièmement, ne pas être tenté de faire un mess sans rapport avec les outils de quand il est originaire et simple d'approche. Ici, il est:

log = logging.getLogger(__name__)

try:
    call_code_that_fails()
except MyError:
    log.exception('Any extra info you want to see in your logs')

Que c'est. Vous êtes maintenant.

Explication pour n'importe qui qui est intéressé par la façon dont les choses fonctionnent sous le capot

Ce log.exception est en train de faire est juste un appel à log.error (qui est, le journal de l'événement avec le niveau ERROR) et impression traceback ensuite.

Pourquoi est-il mieux?

Eh bien, voici quelques considérations:

• c'est juste droit;
• c'est simple;
• c'est simple.

Pourquoi personne ne s'est traceback ou appeler enregistreur avec exc_info=True ou salir les mains avec sys.exc_info?

Bien, tout simplement parce que! Ils existent tous à des fins différentes. Par exemple, traceback.print_exc's la sortie est un peu différent de retraçage produite par l'interprète lui-même. Si vous l'utilisez, vous confondez quiconque lit les journaux, ils vont être frapper leurs têtes contre eux.

Passant exc_info=True pour les appels du journal est tout simplement inapproprié. Mais, il est utile lors de la capture de recouvrable des erreurs et que vous voulez vous connecter (en utilisant, e.g INFO niveau) avec un retraçage en tant que bien, parce que log.exception produit des rapports d'un seul niveau - ERROR.

Et vous avez certainement devraient éviter de jouer avec sys.exc_info autant que vous le pouvez. Il est tout simplement pas une interface publique, c'est de l'intérieur, vous peut l'utiliser si vous savez certainement ce que vous faites. Il n'est pas prévu pour l'impression des exceptions.

Pour obtenir le précis trace de la pile, comme une chaîne de caractères, que serait ont été soulevées si aucun try/except étaient là pour l'étape au-dessus, il suffit de le placer dans le bloc except que les captures de la délinquance exception.

desired_trace = traceback.format_exc(sys.exc_info())

Voici comment l'utiliser (en supposant que flaky_func est défini, et log appels préférée de votre système de journalisation):

import traceback
import sys

try:
    flaky_func()
except KeyboardInterrupt:
    raise
except Exception:
    desired_trace = traceback.format_exc(sys.exc_info())
    log(desired_trace)

C'est une bonne idée de les attraper et de les re-raise KeyboardInterrupts, de sorte que vous pouvez toujours arrêter le programme à l'aide de Ctrl-C. la Journalisation est en dehors de la portée de la question, mais une bonne option est la journalisation. La Documentation pour la sys et traceback modules.

Une remarque sur cette réponsecommentaires: print(traceback.format_exc()) fait un meilleur travail pour moi que traceback.print_exc(). Avec ce dernier, le hello est parfois étrangement "mixte" avec le traceback texte, comme si les deux veulent écrire sur la sortie standard stdout ou stderr dans le même temps, la production bizarre de sortie (au moins lors de la construction de l'intérieur d'un éditeur de texte et l'affichage de la sortie dans les "résultats" du panneau).

Traceback (most recent call last):

Fichier "C:\Users\User\Desktop\test.py", à la ligne 7, dans

l'enfer do_stuff()

Fichier "C:\Users\User\Desktop\test.py", line 4, dans do_stuff

1/0

ZeroDivisionError: integer division ou modulo by zero

o

[Terminé en 0,1 s]

Donc j'utilise:

import traceback, sys

def do_stuff():
    1/0

try:
    do_stuff()
except Exception:
    print(traceback.format_exc())
    print('hello')

Vous voulez le traceback module. Il vous permettra d'imprimer les vidages de pile comme le Python fait normalement. En particulier, la print_last fonction d'impression de la dernière exception et une trace de la pile.

Si vous avez une Erreur de l'objet déjà, et que vous souhaitez imprimer l'ensemble de la chose, vous avez besoin de faire un peu maladroit appel:

import traceback
traceback.print_exception(type(err), err, err.__traceback__)

C'est vrai, print_exception prend trois les arguments de position: Le type de l'exception, à l'exception de l'objet, et à l'exception internes propres à assurer la traçabilité de la propriété.

En python 3.5 ou ultérieure, la type(err) est facultatif... mais c'est une position d'argument, donc vous avez encore à transmettre explicitement Aucun à sa place.

traceback.print_exception(None, err, err.__traceback__)

Je n'ai aucune idée de pourquoi ce n'est pas seulement traceback.print_exception(err). Pourquoi vouloir imprimer une erreur, avec un traceback autre que celui qui appartient à cette erreur, est au delà de moi.