Gestion d'erreurs dans python

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.

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 ...

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

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

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:

bruno@bibi playground $ ps
PID TTY TIME CMD
8950 pts/1 00:00:00 bash
8958 pts/1 00:00:00 ps
bruno@bibi playground $ cat suicide.py
print "hello"
raise Exception("commiting suicide")
bruno@bibi playground $ python suicide.py
hello
Traceback (most recent call last):
File "suicide.py", line 2, in ?
raise Exception("commiting suicide")
Exception: commiting suicide
bruno@bibi 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).

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 :(

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

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...

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 ... :)

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