Rattraper des exceptions

Version imprimable

01/09/2008, 01h17
delire8

Rattraper des exceptions

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
01/09/2008, 10h44
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.
01/09/2008, 12h12
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).
03/09/2008, 01h50
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.
03/09/2008, 09h04
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?
03/09/2008, 11h46
nikko34

ne pas oublier le try...catch( ... ) dans la fonction principale des threads aussi
03/09/2008, 14h14
loufoque

Citation:

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.

Ça s'appelle l'exception-safety basique.
C'est absolument automatique si tu programmes en C++ correctement, c'est à dire avec le RAII.
03/09/2008, 20h45
Klaim

loufoque> Je suis d'accord, mais parfois c'est loin d'être "automatique", même si on ne fait que du RAII (ce que je fais, dans mon propre code) ...

Il y a des cas ou le RAII n'est pas "absolu", comme par exemple quand on a une exception déclenchée par une lib , encapsulée auparavant disons, puis un catch qui tente alors de désallouer les resources de la lib en question (via le destructor par exemple) et qui déclenche alors une autre exception, typiquement dépendante d'un cas spécifique issu de la première exception, et du coup certaines resources ne sont pas libérées. Là il faut alors gérer du cas spécifique où du leak est possible, mais dans tous les cas mènera à la fin de l'application (donc potentiellement dans ce cas, moins d'infos de debug par exemple, mais au moins on arrête l'appli).

Je pense pas que j'ai été très clair....... mais en gros à un certain niveau de complexité, ce n'est pas forcément évident. Surtout quand on manipule des libs externes. (auquel cas le probleme peut bien évidement venir de la lib, mais d'un point de vue de l'utilisateur, c'est votre problème quand même, donc faut gérer plein de trucs suplémentaires, d'où une perte de temps potentielle non négligeable).

Evidemment, si on a que son propre code, effectivement c'est "absoluement automatique".

En tout cas, on a pas mieu que la RAII pour gérer tout ça, c'est sur.

Je trouve que le terme RAII ne fait pas justice au concept. C'est pourquoi je lui préfère le terme RRIF (Resource Release Is Finalization), beaucoup plus parlant à mes yeux. La preuve:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class FichierLecture
{
public:
	FichierLecture(const char *fileName) : m_pfIn(fopen(fileName, "r"))
	{
		if(m_pfIn==NULL)
			throw new std::exception("Echec d'ouverture de fichier");
	}
	//Pas de destructeur:
	//La ressource est leakée,
	//et pourtant je l'ai acquise lors de l'initialisation!
	std::string ReadLine();
	void Close();
private:
	FILE * m_pfIn;
};

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
class FichierLecture
{
public:
	FichierLecture() : m_pfIn(NULL)
	{ }
	//Destructeur présent:
	//La ressource sera toujours libérée, 
	//Et pourtant je ne l'ai pas acquise lors de l'initialisation...
	~FichierLecture()
	{
		Close();
	}
	std::string ReadLine();
	void Close()
	{
		if(m_pfIn!=NULL)
		{
			fclose(m_pfIn);
			m_pfIn = NULL;
		}
	}
	void Open(const char *fileName)
	{
		Close();
		assert(m_pfIn==NULL); //Close() doit l'avoir remis à NULL
		m_pfIn = fopen(fileName, "r");
		if(m_pfIn==NULL)
			throw new std::exception("Echec d'ouverture de fichier");
	}
private:
	FILE * m_pfIn;
};

04/09/2008, 14h47
loufoque

Citation:

Il y a des cas ou le RAII n'est pas "absolu"

Si si. Ça se démontre.

Citation:

comme par exemple quand on a une exception déclenchée par une lib , encapsulée auparavant disons, puis un catch qui tente alors de désallouer les resources de la lib en question (via le destructor par exemple) et qui déclenche alors une autre exception, typiquement dépendante d'un cas spécifique issu de la première exception, et du coup certaines resources ne sont pas libérées. Là il faut alors gérer du cas spécifique où du leak est possible, mais dans tous les cas mènera à la fin de l'application (donc potentiellement dans ce cas, moins d'infos de debug par exemple, mais au moins on arrête l'appli).

Ton exemple est incompréhensible.
Un destructeur doit être nothrow. Et toute libération de ressource doit se faire dans le destructeur, certainement pas ailleurs (enfin, dans operator= ou dans les constructions de mouvement éventuellement, mais ça peut s'exprimer plus élégamment avec swap)

@Medinoc:
Le cas sans état vide est simple. Constructeur : fopen (exception en cas d'échec), Destructeur : fclose. Pas de fonction membre Close.
Avoir un état vide ne veut pas dire que tu n'es pas conforme au RAII, ça veut simplement dire que les invariants de ton objet sont différents. Je trouve personnellement plus utile de maintenir l'invariant qu'on a toujours une ressource que de permettre d'avoir un objet dans un état vide et avec lequel on ne peut rien faire sans risquer que tout nous pète à la gueule.
On remarquera d'ailleurs que dans les deux cas il te faut désactiver operator= et le constructeur de copie sous peine d'avoir de gros problèmes.
Par ailleurs, avec ton second code, si on a déjà une ressource et qu'on tente d'en ouvrir une autre et que cela échoue, on se retrouvera avec plus rien. Super...
04/09/2008, 22h31
Klaim

Citation:

Ton exemple est incompréhensible.

Désolé, je manque de sommeil. C'est un ensemble vraiment complexe et c'est difficile a expliquer.

Citation:

Si si. Ça se démontre.

Je veux bien voir ça. :)

Citation:

Un destructeur doit être nothrow.

Je ne suis pas d'accord, j'ai un cas ultra rare (unique dans mon experience personnelle) où j'ai un destructeur avec un throw, qui est non seulement utile mais aussi indispensable.

Citation:

Et *toute* libération de ressource doit se faire dans le destructeur, certainement pas ailleurs.

Comme je disais, en théorie je suis d'accord (et c'est ce que je fais dans mon code). Dans la pratique il y a des "cas" (qui sont issues de cas complexes) pour lesquels c'est tout simplement faux.
05/09/2008, 02h14
loufoque

En général, si tu ne peux pas libérer une ressource, il n'y a rien d'intelligent que tu puisses faire à part signaler l'erreur.
05/09/2008, 09h31
Médinoc

+1 pour Loufoque.
The Old New Thing : Clean-up functions can't fail because, well, how do you clean up from a failed clean-up?
05/09/2008, 20h52
Klaim

Loufoque> Oui! C'est bien ce que je fais, j'ai juste fais mon maximum eviter ce genre de cas et avoir un max d'infos quand on y arrive quand même.