Il y a des mois de ça, j’avais écris un article sur atexit, un module qui permet de lancer une fonction à la fermeture de la VM Python.
Ces fonctions sont appelées même si la VM s’arrête brutalement, mais on a aucune information sur la raison de l’arrêt de la machine virtuelle Python. Et elles sont exécutées même si tout s’est bien passé.
Si vous voulez réagir au plantage de votre programme, et seulement au plantage, tout en ayant en plus des informations sur la nature du foinage :
import sys def on_crash(type, value, tb): print type print value print tb sys.excepthook = on_crash declencher_erreur = 1 + "1" ## <type 'exceptions.TypeError'> ## unsupported operand type(s) for +: 'int' and 'str' ## <traceback object at 0x00543AF8> |
Ca peut être très intéressant pour débugger un processus détaché comme par exemple votre serveur WSGI qui fait tourner Django qui décide de se petit-suicider : demandez à sys.excepthook de faire un dump de l’exception dans un fichier log , et vous pourrez voir ce qui a propoqué la crise.
Si vous êtes du genre poli, vous voudrez quand même garder l’ancien comportement de sys.excepthook, qui est toujours disponible depuis sys.__excepthook__ :
def on_crash(type, value, tb): # faire ce que vous voulez ici puis... sys.__excepthook__(type, value, tb) |
Et dire que vous commenciez à croire que vous saviez presque tout sur Python. Mouarf.
J’ai utilisé ce mécanisme en association avec logging pour m’envoyer un mail en cas d’événement critique.
Ce qui en passant m’a amené overrider SMTPHandler de loggin.handlers qui avait un problème avec l’encodage (@kontre): ce con ne connaissant que l’ascii, je l’ai adapté pour qu’il accepte de l’unicode et sorte de l’utf-8 dans le sujet et le corps du message.
J’ai pas mal appris en 6 mois, mine de rien (clap, clap, clap! Bravo Etienne)
Ce sujet m’intéresse. Y aurait moyen que tu nous fasse pêter le code source (ou si tu as le temps, carrément un article ?).
En particulier la partie SMTP avec le bug et tout le bordel.
Ok, je verrai ça demain
Pourquoi la coloration syntaxique met-elle en vert l’argument ou la variable “type” dans les exemples de code ?
Parce que “type” est une méthode built-in. Pour éviter de l’écraser, utilisez un autre nom ou “_type” comme on le voit souvent. Cela évitera de chercher des heures pourquoi type(value) is not callable.
En fait pour faire ça proprement il faudrait appeler les argument “etype” et “evalue” qui sont les noms des arguments de la fonction originale.
Raaaaah mais c’est excellent !!
En effet, avec ça toute erreur non échappée va tomber dans ma boite mail (ou un ptit sqlite en partage), géniaaaal.
Vais me faire spammer par tout le studio^^.
Ah bah non, fallait que le logiciel à 8K qui bind mon python ne le permette pas (je cherche encore la raison)…
CHIENNE de vie.
8Ko ou 8k€ ?
nieuros, mais je suis taquin, “ils” nous font payer 1000 boules la “feature” license flottante.
Bad mood inside^^.
A côté de ça, Blender est en python3, LUI *soupire*.
Il n’est jamais trop tard : « et vous pourrez voir ce qui a propoqué la crise. »
À remplacer par : et vous pourrez voir ce qui a provoqué la crise. (avec un « v » à provoqué)