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.