Gestion d'erreurs dans python

Le
ian
Bonjour,

Ayant donne la chance a python (contre l'avis de la direction :p) il
s'avere que j'ai eu raison Nous avons d'excellents resultats en terme de
dev, de vitesse (c'etait la principale crainte) et il tient ses promesses:
on peut utiliser le meme code sur PC X86 comme sur le materiel embedded,
qu'il soit en SH3 ou en ARM La classe! :)

Maintenant, une question : la gestion des erreurs. Quand ca plante quelque
part, il indique l'erreur etcetc, le module qui a plante ne tourne plus,
mais le reste si, ce qui donne une impression que le soft tourne toujours
mais avec une partie en moins.. Pas pratique.
Je me suis dit qu'il devait y avoir un parametre a passer a python pour
qu'il sorte (ou relance) automatiquement a la moindre erreur, stype
python -onerrorrestart xxx.pyc, vous voyez le genre .. et la, dans la doc,
horreur, je trouve rien

Donc, comme il est impossible de tout prevoir, et que je ne peux pas mettre
de try catch partout, existe-t-il un moyen de dire a python de fermer ou
relancer le soft des qu'une erreur (grave ou non) apparait ?

Merci
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bruno Desthuilliers
Le #588742
Bonjour,

Ayant donne la chance a python (contre l'avis de la direction... :p) il
s'avere que j'ai eu raison ... Nous avons d'excellents resultats en terme de
dev, de vitesse (c'etait la principale crainte) et il tient ses promesses:
on peut utiliser le meme code sur PC X86 comme sur le materiel embedded,
qu'il soit en SH3 ou en ARM ... La classe! :)

Maintenant, une question : la gestion des erreurs. Quand ca plante quelque
part, il indique l'erreur etcetc, le module qui a plante ne tourne plus,
mais le reste si,


Heu... Qu'appelle-tu "module" dans ce contexte, au juste ?


ce qui donne une impression que le soft tourne toujours
mais avec une partie en moins.. Pas pratique.
Je me suis dit qu'il devait y avoir un parametre a passer a python pour
qu'il sorte (ou relance) automatiquement a la moindre erreur, stype
python -onerrorrestart xxx.pyc, vous voyez le genre .. et la, dans la doc,
horreur, je trouve rien...


Normalement, une exception non gérée entraine la mort de l'interpréteur
dans lequel s'est produit cette exception.

ian
Le #588741
Heu... Qu'appelle-tu "module" dans ce contexte, au juste ?


Par exemple, j'ai main.py, puis x.py, y.py et z.py ... Une erreur se produit
dans x.py, il ne tourne plus, alors que main.py, y.py et z.py continuent de
tourner

Normalement, une exception non gérée entraine la mort de l'interpréteur
dans lequel s'est produit cette exception.


Et bien non, python ne quitte pas, puisque, comme dans l'exemple donne plus
haut, 2 units continuent de tourner ... et c'est bien ca le probleme ... Si
python s'arretait, je pourrais via un script bash relancer l'application ...

William Dode
Le #588740
On 07-03-2007, ian wrote:

Heu... Qu'appelle-tu "module" dans ce contexte, au juste ?


Par exemple, j'ai main.py, puis x.py, y.py et z.py ... Une erreur se produit
dans x.py, il ne tourne plus, alors que main.py, y.py et z.py continuent de
tourner


Tu veux dire que tu lances plusieurs interpréteurs ? Un par script ?


Normalement, une exception non gérée entraine la mort de l'interpréteur
dans lequel s'est produit cette exception.


Et bien non, python ne quitte pas, puisque, comme dans l'exemple donne plus
haut, 2 units continuent de tourner ... et c'est bien ca le probleme ... Si
python s'arretait, je pourrais via un script bash relancer l'application ...





--
William Dodé - http://flibuste.net
Développeur informatique indépendant


Laurent Pointal
Le #588739
ian wrote:


Heu... Qu'appelle-tu "module" dans ce contexte, au juste ?


Par exemple, j'ai main.py, puis x.py, y.py et z.py ... Une erreur se
produit dans x.py, il ne tourne plus, alors que main.py, y.py et z.py
continuent de tourner

Normalement, une exception non g




Bruno Desthuilliers
Le #593849
Heu... Qu'appelle-tu "module" dans ce contexte, au juste ?



Par exemple, j'ai main.py, puis x.py, y.py et z.py ... Une erreur se produit
dans x.py, il ne tourne plus, alors que main.py, y.py et z.py continuent de
tourner


Je ne peux que répéter la question de William. En Python, un module est
un fichier ou paquetage importé par le programme principal (ou par un
module lui-même importé par, etc...). Bref, il n'y a dans ce cas qu'un
seul processus. Donc, tes x/y/x/*.py sont-ils importés par main.py, ou
bien s'agit-il de processus autonomes (chacun son interpréteur) ?


Normalement, une exception non gérée entraine la mort de l'interpréteur
dans lequel s'est produit cette exception.


Et bien non, python ne quitte pas,


Si tu a un seul interpréteur Python exécutant main.py, lequel importe x,
y et z, une exception *non gérée* (j'insiste) provoque le suicide de
l'interpréteur. Tu peux aisément t'en assurer par toi-même:

playground $ ps
PID TTY TIME CMD
8950 pts/1 00:00:00 bash
8958 pts/1 00:00:00 ps
playground $ cat suicide.py
print "hello"
raise Exception("commiting suicide")
playground $ python suicide.py
hello
Traceback (most recent call last):
File "suicide.py", line 2, in ?
raise Exception("commiting suicide")
Exception: commiting suicide
playground $ ps
PID TTY TIME CMD
8950 pts/1 00:00:00 bash
8958 pts/1 00:00:00 ps

Si tu n'a pas le même résultat, tu viens de mettre le doigt sur un bug.
Mais honnêtement, je doute.

Maintenant, si tu lance plusieurs interpréteurs (un pour main, un pour
x, etc) communiquant entre eux d'une façon ou d'une autre, il n'y a bien
sûr aucune raison que la mort d'un de ces processus entraine la mort des
autres (à moins que tu ne fasse explicitement en sorte que ce soit le cas).


ian
Le #593846
Re tous,

J'ai surement pas ete clair et incomplet donc je complete :)

la main importe tous les autres, il y a bien qu'un seul python qui tourne...

J'ai fait quelques tests, effectivement si je mets une exception dans la
partie __main__ de n'importe quel module, python s'arrete... mais un module
(.py) = un ou plusieurs threads, si ca arrive dans un thread, le reste ne
s'arrete pas, voila pourquoi j'avais vu ca ...
D'un autre cote, si un thread meurt, c'est normal que python s'arrete pas
(oui j'ai honte :p)
Donc ... maintenant que je sais ou mettre le doigt, ca va etre plus facile
de vous demander :)

Y-a-t-il un moyen de voir qu'un thread est mort, sans avoir a mettre une
boucle qui check le(s) thread(s) ?
les events de delphi me manque :(
ian
Le #593697
Bon apparement on peut le savoir avec IsAlive() mais ca implique de devoir
faire une boucle de test pour chaques threads :(
Bruno Desthuilliers
Le #591267
Bon apparement on peut le savoir avec IsAlive() mais ca implique de devoir
faire une boucle de test pour chaques threads :(



Je n'ai pas l'habitude de bosser avec les threads, donc je vais
peut-être dire une connerie, mais est-ce qu'il n'aurait pas moyen de
passer une callback à la création des threads, laquelle serait appelée
par le thread en cas de défaillance, de façon à signaler le problème ?

ie, dans le thread:
try:
do_the_job()
except Exception, e:
callback(e) # signale qu'on va mourrir et pourquoi
raise

Ceci étant, si c'est un problème récurrent, il serait peut-être
préférable de corriger la cause, non ?-)

Mes deux centimes...

ian
Le #591266
ie, dans le thread:
try:
do_the_job()
except Exception, e:
callback(e) # signale qu'on va mourrir et pourquoi
raise


peut etre une solution oui... Je vais voir comment on gere un callback sous
python


Ceci étant, si c'est un problème récurrent, il serait peut-être
préférable de corriger la cause, non ?-)


Si seulement on pouvait tout prevoir ... :)
Le probleme c'est que ca tourne chez des clients, sans ecran ni clavier
(embedded) et que ca doit donc etre stable ET autonome

La precedente version etait en C++, et tournait avec le watchdog du SH3
(tres pratique, en gros, dans chaques threads, on signale au watchdog qu'on
est toujours la, et si le cpu ne recoit plus un signal d'un thread, hop,
reset ... donc pour n'importe quel plantage on etait sur d'avoir un reset et
donc une remise en marche 10 secondes apres)

Maintenant, sous ARM, faut faire sans ... :)

NicolasP
Le #591265
Bon apparement on peut le savoir avec IsAlive() mais ca implique de devoir
faire une boucle de test pour chaques threads :(


Sauf si tu mets un énorme try et un petit except:


début thread
try :
contenu du thread
except :
envoie un évènement au programme principal
fin thread


C'est du bricolage mais ça peut dépanner.
Bonjour le débuggage à moins que tu fasses comme ça :

début thread
try :
contenu du thread
except :
affichage des infos de trace de l'exception
envoie un évènement au programme principal
fin thread

Nicolas

Publicité
Poster une réponse
Anonyme