Discussion :

[delire8]

Bonjour,

Je ne suis pas familié de la gestion des exceptions, mais j'essaye de les utiliser. Une question reste, pour moi, en suspens : quelle est la meilleure place pour le bloc try/catch dans un programme win32 ?

Est-ce dans la CallBack principale ? Dans la boucle "while( GetMessage(...) )" ? Ailleurs ? Où vaut mieux-t-il faire du cas par cas, en plaçant ces blocs de manière locale au même endroit que les exceptions potentielles ??

merci

Cordialement

[themadmax]

Pour la gestion des exceptions je ne pense pas qu'il existe de difference sinificative en un prog. Win32 et un autre. Les blocs try/catch doivent se trouver ou tu pourras evidement effectué un code tierce pour ta gestion de ton exception. Pour ma philo. : une exception ne sert que pour la gestion des erreures gravent.

[Laurent Gomila]

La meilleure place pour un bloc try / catch c'est le premier endroit dans la pile d'appels où l'on peut faire quelque chose de pertinent avec l'exception. Tant que tu n'as rien d'intelligent à faire avec, laisse la remonter.

Si toutes tes exceptions sont des erreurs fatales et que tu ne veux qu'afficher un message avant de quitter, tu peux très bien te retrouver avec un unique bloc try / catch autour du contenu de ton main (WinMain dans ce cas).

[Klaim]

Pareil que Laurent.
Pour donner un exemple concret, sur le jeu sur lequel je bosse personnellement j'ai un try a des endroits stratégiques :

a) dans le main, pour catcher "toutes" les exceptions, de manière à ensuite pouvoir fournir une interface (pour l'instant une boite de dialogue basique) qui permet d'envoyer des informations de debuggage automatiquement sur une boite mail (pour gagner du temps en beta test par exemple) - quel que soit le type d'erreur. J'envoie un fichier de log constitué par les catch suivants...

b) dans la fonction d'initialisation des systemes de base : le tout est de récupérer les exceptions correspondant à des problèmes de relation software hardware, comme par exemple le cas ou la machine n'a pas les resources nécessaires (carte graphique souvent) pour faire tourner le jeu.
Je ne fais qu'un log de l'erreur avant de faire throw pour que ce soit intercepté plus haut, au niveau de a)

c) même chose mais à la libération des resources system (ça peut être de bons indices pour des bugs qui se déroulent pendant le jeu)

d) un try autour de la boucle principale du jeu, toujours de la même manière, simplement pour logger les exceptions que je connais.

e) un try lors de l'aquisition du clavier et de la souris : je catch une exception specifique a l'api gérant ces entrées, puis je relance une exception spécifique à mon application derrière avec des infos suplémentaires.


En revanche, j'ai mis pas mal de temps pour faire en sorte que même si il y a catch appelé, il n'y ai "presque" jamais de mémory leak, même si ça remonte jusqu'au main. On peut penser que c'est inutile puisque l'application va de toutes manières se terminer, mais ça permet aussi de pouvoir plus tard gérer des choses autour de l'application sans souci quand il y a eu un problème grave.

Mettre en place sa stratégie concernant les exception est important mais surtout a ne pas prendre à la légère.

[3DArchi]

Dans l'idée, c'est effectivement de traiter l'exception là où tu pourras retomber sur tes pieds. Par exemple, une exception sur une fonction de ton soft peut être traitée par là où elle est invoké pour signalé son échec et permettre à l'appli de continuer à tourner. Une exception amenant à corrompre tes données sera probablement traité à un plus haut niveau et aboutira probablement à l'arrêt du soft ou à la fermeture du document ou une procédure de recouvrement de données, etc... En fait, il est important de se dire: que puis-je faire de cette exception par rapport à l'état du logiciel?

[nikko34]

ne pas oublier le try...catch( ... ) dans la fonction principale des threads aussi