Discussion :

[Talsaj]

Bonjour à vous, je suis en train d'apprendre le python et je me rends compte que j'ai pas une bonne visibilité des problèmes que mon code rencontre, je me suis donc renseigné sur les exceptions, rien de bien mais sorcier mais je me demande comment en pratique les gens sachant y faire s'en servent. Ceci est donc la question, comment procédez vous pour savoir ou ça merde quand ça merde. Si un habitué pouvait me partager ses réflexes et bonnes habitudes qu'il applique sur chaque projet concernant les erreurs et exceptions qu'il pourrait rencontrer. Merci à ceux qui vont répondre et merci aux autres d'avoir pris le temps de lire.

[Sve@r]

Bonjour

Pour savoir où ça merde quand ça merde, c'est pas compliqué: quand ça merde et que c'est pas protégé par un try/except, alors ça te remonte tout à la figure avec la pile des appels. Ne te reste ensuite qu'à aller voir la dernière ligne indiquée. Si cette ligne te semble correcte, alors tu remontes la précédente, et etc jusqu'à trouver la ligne qui a provoqué l'erreur.

Prenons un exemple simple: tu calcules une division à la con => def inv(): return 1/0. Ici c'est clair que tout appel de "inv" provoquera une exception. Et que la dernière ligne indiquée par la stack trace sera celle où il y a l'erreur.

Si maintenant on a le code suivant

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
def inv(x): return 1/x
 
def calcul():
	x=int(raw_input("Entrez une nombre :"))
	print inv(x)

Il est clair que si tu as un ZeroDivisionError, ce n'est pas l'inversion qui est en cause mais le nombre saisi. Donc ce ne sera pas la dernière ligne affichée par la stack trace qui sera à revoir mais l'avant dernière.
Et ainsi de suite.

Maintenant où placer la sécurité ? Pour moi, c'est au moment où un travail devient "atomique" (ça passe ou ça casse). Par exemple je travaille avec des bases de données. Et aussi des formulaires de saisie de ces données. Bien entendu, le formulaire correspond à une vision "humaine" de la donnée (exemple nom, prénom, immatriculation) tandis qu'en base, ces données sont éclatées dans les diverses tables (table des personnes, table des véhicules).
Fatalement, à un moment donné, il y aura 2 insertions de ces données en bdd (insertion du nom et prénom dans la table des personnes, insertion de l'immatriculation dans la table des véhicules).
Exemple

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
insert(table="personne", data={"nom" : nom, "prenom" : prenom})
insert(table="vehicule", data={"immatriculation" : immat})

Où va-t-on devoir placer le try/except ? Si on le place dans la fonction "insert", alors on prend le risque que l'une des deux insertions échoue (mais le try/except prend le relai et le programme ne plante pas) tandis que l'autre réussira. Et on aura au final un véhicule sans propriétaire ou un propriétaire sans véhicule.
Donc non. L'atomicité des opérations veut que les deux insert se fassent ou aucun. Donc le try/except englobera les deux insert...

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
try:
	insert(table="personne", data={"nom" : nom, "prenom" : prenom})
	insert(table="vehicule", data={"immatriculation" : immat})
except DatabaseError:
	rollback();
# try

... tandis que la fonction "insert", elle, se contentera de passer l'ordre sans se protéger de quoi que ce soit. Si souci il y a, c'est son appelant qui gèrera.

En espérant t'avoir aidé.

[Talsaj]

Merci beaucoup ,la réponse est très clair et détaillée, je pense avoir compris l'utilisations des blocs try, j'ai l'habitude de rendre mon code "bavard" en mettant des print un peu partout, mais au final je me dis que peut-être c'est une mauvaise habitude, j'aurai aimé savoir ce que vous pensiez de cette "manie". Merci à vous

[lg_53]

Non c'es très bien de mettre des print partout pour contrôler pas après pas la validité de ce qui est fait par le code.
Après effectivement ca pollue la sortie. Donc idéalement quand on développe, on les mets, et juste à la fin on les commente tous pour garder que ceux qui sont nécéssaire.

Après le print c'est bien mais ca vous oblige à faire le controle vous même (c'est à dire regarder si là, ça a bien affiché tel truc, etc ...). Il existe tout de même un moyen de contrôler les choses, de ne rien afficher si ca se passe bien, et de faire cracher une erreur si ca ne se passe pas comme attendu : le assert

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a=1
assert(a!=0),'(Verif1) a doit etre different de 0!'
a=0
assert(a!=0),'(Verif2) a doit etre different de 0!'

NB: (Verif1) et (Verif2) ne servent à rien dans l'identification de l'erreur, mais dans cette exemple ca vous permet de voir lequel s'enclenche.

[Sve@r]

j'aurai aimé savoir ce que vous pensiez de cette "manie". Merci à vous

Tu devrais t'intéresser au module "logging" qui est tout adapté à ça. Plus de détails ici...

[Talsaj]

Les réponses arrivent vite ici, merci à vous, je me renseigne donc sur assert et sur le module logging qui je dois l'avouer m'a l'air un peu compliqué pour l'instant. Sujet résolu