Eviter fermeture fenêtre en pyw

Bonjour,

J'ai un <<assez gros>> programme (du moins pour moi) utilisant le module tkinter et il y a des petits bugs qui ne sont pas bloquants (et que j'essaie de corriger au fur et à mesure). Mon éditeur de python est Idle.
Lorsque je lance mon programme à partir d'Idle (en tapant F5) et qu'il y a un petit bug, sur une fenêtre Python, il m'affiche l'origine de l'erreur mais mes fenêtres ouvertes par mon programme restent ouvertes et le programme continue à tourner (et je peux continuer à l'utiliser)
Par contre, si je lance directement mon programme (en pyw). Dès que le pg rencontre un bug, tout le programme s'arrête et il y a fermeture de toutes les fenêtres.
Ma question est la suivante: existe-t-il une commande ou une procédure qui évite l'arrêt total du pg lors de la rencontre d'un petit bug et lorsque ce programme est lancé directement sans passer par l'éditeur de Python?
Je ne sais pas si ma question est claire...
En tout cas merci pour vos éventuelles réponses.
Gabriel

Salut,

Citation:

---

Envoyé par Ruyneau

Ma question est la suivante: existe-t-il une commande ou une procédure qui évite l'arrêt total du pg lors de la rencontre d'un petit bug et lorsque ce programme est lancé directement sans passer par l'éditeur de Python?

---

Sous IDLE, le programme est lancé dans un process "à part" et s'il y a des échanges, ils sont fait via RPC. Cela construit une étanchéité entre IDLE et le programme: si le process "à part" se plante, IDLE y survivra.
Ceci dit, le petit "bug" aura quand même provoqué la destruction du process (et la perte de l'état du programme qu'il faudra relancer du début).

Ceci dit un bug reste la transition dans un état que le code est incapable de traiter qui se traduit en général par la levée d'une exception tôt ou tard.

Et la notion de "petit bug" pourrait être définir par des transitions dans un état qui permette quand même de continuer les opérations dans un mode +/- dégradé.

Exemple:
Le programme demande à l'utilisateur un nom de fichier à ouvrir en lecture.

Appeler open(nom, 'r') sans avoir vérifier que le fichier "nom" existait va lever l'exception: IOError: [Errno 2] No such file or directory: "nom"
Plutôt que de "vérifier", on peut attraper l'exception:

Code:

---

1 2 3 4

try: f = open(nom, 'r') except IOError: # que faire ici pour que le bug soit 'petit'?

---

Autre approche.
Le code que j'écris n'est jamais sans "bug". J'utilise logging de façon extensive vérifier que certains états sont "as expected" mais il y a toujours des imprévus. On peut ajouter l'affichage d'informations supplémentaires pour savoir ce qu'il se passe et relancer... mais l'exercice est un peu harassant.

J'utilise un module debug.py qui me permet de lancer le debugger en post mortem:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

import sys   def pm_debug(type, value, tb): """traitement normal des exceptions en mode interactif ou sans console     sinon on affiche l'exception puis on lance le debugger en mode pm     """ if hasattr(sys, 'ps1') or not sys.stderr.isatty(): sys.__excepthook__(type, value, tb) else: import traceback, pdb traceback.print_exception(type, value, tb) pdb.post_mortem(tb)   sys.excepthook = pm_debug

---

Ca s'utilise comment? Soit par exemple ce code qui lève une exception de division par 0:

Code:

---

1 2 3 4

def foo(a, b): return a / b   foo(1, 0)

---

Lorsqu'on le lance, çà plante et il ne reste qu'a interpréter la trace pour savoir ce qui pèche (ok, ici c'est facile):

Code:

---

1 2 3 4 5 6 7 8

C:\py_works>py -3.2 demo.py Traceback (most recent call last): File "demo.py", line 5, in <module> foo(1, 0) File "demo.py", line 3, in foo return a / b ZeroDivisionError: division by zero C:\py_works>

---

Si on ajoute "import debug", lorsque çà plante, on récupère le debugger!

Code:

---

1 2 3 4 5 6 7 8 9 10

C:\py_works>py -3.2 demo.py Traceback (most recent call last): File "demo.py", line 6, in <module> foo(1, 0) File "demo.py", line 4, in foo return a / b ZeroDivisionError: division by zero > c:\py_works\demo.py(4)foo() -> return a / b (Pdb)

---

On pourra alors examiner ce qui s'est passé et corriger (plus vite?)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

(Pdb) list 1 import helpers.debug 2 3 def foo(a, b): 4 -> return a / b 5 6 foo(1, 0) [EOF] (Pdb) print a 1 (Pdb) print b 0 (Pdb)

---

Je ne suis pas sur que cela réponde à votre question.
J'espère vous avoir donné une idée d'approche...

- W

Bonjour,

Cà ne répondait pas à ma question initiale, mais comme laisser des pgs avec des <<petits>> bugs, ce n'est pas génial, je vais essayer d'utiliser votre debugger pour trouver et corriger plus rapidement les erreurs.
J'utilise rarement la commande <<try>> qui me semble réellement un plus. Je ne vois pas trop comment elle fonctionne (surtout dans la partie except).
Effectivement mes petits bugs sont l'ouverture des fichiers qui n'existent pas ou bien la récupération d'une fenêtre (tkinter) qui n'existe plus.
Peut être que try me suffirait pour résoudre le pb.

Gabriel

rebonjour

J'ai essayé avec import debug.py.

Pas de soucis lorsqu'on lance un programme.py ; l'erreur s'affiche sur la console.

Par contre, avec programme.pyw, aucun message ne s'affiche et je ne sais pas où aller chercher le fichier recensant le bug... qui doit être bien quelque part

Merci de votre aide

Gabriel

Salut,

Citation:

---

Envoyé par Ruyneau

Par contre, avec programme.pyw, aucun message ne s'affiche et je ne sais pas où aller chercher le fichier recensant le bug... qui doit être bien quelque part

---

C'est normal, çà dit:

Code:

---

1 2 3 4

def pm_debug(type, value, tb): """traitement normal des exceptions en mode interactif ou sans console sinon on affiche l'exception puis on lance le debugger en mode pm """

---

.PYW est justement "sans console".

Ceci dit, si le programme plante "sans" console, il plantera (probablement) aussi "avec"...
- W

honte à moi... je n'avais pas lu le commentaire du pg...

OK.

Merci

Gabriel