Discussion :

[ram-0000]

Bonjour,

dans ce code:

Code :

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

1
2
3
4
5
6
7
8
9
10
int a;
try
{
	a = 12;
}
catch(...)
{
	assert(false); // warning compilateur ici
}

J'ai un warning du compilateur qui me dit :

warning C4702: impossible d'atteindre le code

Le warning est sur la ligne de l'assert et je ne comprends pas pourquoi.
Bon, là, c'est un code minimal mais normallement dans le bloc try, il y a plein de choses.

Mon environnement de développement,
Visual Studio 2005 SP1 sur XP pro SP3, tout le monde est à jour des mises à jour.

Je compile une DLL,
la ligne de commande du compilateur est :

Code :

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

/Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_USRDLL" /D "WINLOG_EXPORTS" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W4 /nologo /c /Wp64 /ZI /TP /errorReport:prompt

La ligne de commande du linker est :

Code :

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

/OUT:"D:\Raymond\Developpement\WinLog\Debug\WinLog.dll" /INCREMENTAL /NOLOGO /DLL /MANIFEST /MANIFESTFILE:"Debug\WinLog.dll.intermediate.manifest" /DEBUG /PDB:"d:\Raymond\Developpement\WinLog\Debug\WinLog.pdb" /SUBSYSTEM:WINDOWS /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

Si vous avez des idées, je suis preneur

[Florian Goo]

Je suppose que tu as le même warning avec un code moins trivial qu'une affectation à un int, sinon tu ne poserais pas la question, n'est-ce pas ?

[Alp]

Ca se comprendrait que ce ne soit pas le cas, car a = 12 quand a est de type int ne lèvera jamais d'exception.

Mais ça me semble bizarre que le compilo regarde si le code lèvera effectivement une exception ou non...

[ram-0000]

Je suppose que tu as le même warning avec un code moins trivial qu'une affectation à un int, sinon tu ne poserais pas la question, n'est-ce pas ?

Yes sir !!
Le code dans le bloc try est un tout petit peu plus complexe, j'ai simplifié
En fait, dans le bloc try, il y a des sprintf et des manipulation de chaines de caractères

[Alp]

Tu peux nous le donner, car il semble que ce soit le contenu du try qui pose problème, bien que je n'en sois pas sûr.

[Alp]

http://bytes.com/groups/c/484825-unreachable-code
pourrait éventuellement aider.

[Florian Goo]

Hélas, je ne peux pas reproduire avec GCC

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <cassert>
 
int main()
{
	int a;
	try
	{
		a = 12;
	}
	catch(...)
	{
		assert(false); // warning compilateur ici
	}
}

Code :

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

1
2
 
g++ main.cpp -W -Wall -pedantic

[ram-0000]

Ce code reproduit le warning

Code :

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

1
2
3
4
5
6
7
8
9
10
int a = 12;
int b = 0;
try
{
	a = a / b;
}
catch(...)
{
	assert(false);
}

Avec le débugger, j'ai effectivement une exception qui est levée mais je ne passe pas dans le bloc catch

Est ce qu'il est possible que la déclaration/définition de la fonction y soit pour quelque chose :

Code :

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

1
2
3
4
5
6
7
8
 
#ifdef  __cplusplus
extern "C" {
#endif
__cdecl int WinLogW(const int Event, const int FeatureLevel, const wchar_t * Format, ...);
#ifdef  __cplusplus
}
#endif

Le fait que cela soit une fonction "C" avec __cdecl

Petit rappel, je compile une DLL

[ram-0000]

http://bytes.com/groups/c/484825-unreachable-code
pourrait éventuellement aider.

Bonne réponse Alp, c'est cela

I would assume that "C" functions must not throw, so any function is not expected to throw and code is not prepared to catch the exception raised by a "C"-function (->unreachable code)

[koala01]

Salut,

N'oublie pas qu'une division par 0 ne lance pas une exception...

Cela lance un signal d'erreur (SIGFPE -- FPE_INTDIV_TRAP ou FPE_FLTDIV_TRAP)

Outre le fait que try... catch ne fonctionne pas en C, tu dois donc tester la valeur du diviseur avant de laisser ce signal survenir (ou trouver le moyen de l'attraper, mais je crains que ca ne provoque un exit() impossible à attraper)...

En C, tu pourrait déjà faire un simple assert(b!=0), voire passer par un code sensiblement proche de

Code :

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

1
2
3
4
5
6
7
8
if(b==0)
{
    /*que faire si le diviseur vaut 0 */
}
else
{
    traitement "normal"
}

En C++, tu pourrais en arriver à un

Code :

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

1
2
3
4
5
6
7
8
9
try
{
    if(b==0)
        throw DivideByZero();
}
catch(DivideByZero const& ex)
{
    /* ce qu'il faut faire */
}

[ram-0000]

N'oublie pas qu'une division par 0 ne lance pas une exception...

Cela lance un signal d'erreur (SIGFPE -- FPE_INTDIV_TRAP ou FPE_FLTDIV_TRAP)

La nuance est peut être subtile mais le résultat est le même, cela passe (ou devrait passer) dans le catch sauf dans le cas de ma fonction "C" puisque les exceptions ne sont pas gérées par le code assembleur généré (structure de la pile ?)

Outre le fait que try... catch ne fonctionne pas en C

C'est du code C++ compilé par un compilateur C++ avec comme particularité que la fonction doit pouvoir être appelée en C et donc elle possède un interface C.

tu dois donc tester la valeur du diviseur avant de laisser ce signal survenir (ou trouver le moyen de l'attraper, mais je crains que ca ne provoque un exit() impossible à attraper)...

La division par 0 est un exemple minimal qui reproduisait mon problème de "code unreachable" mais qui n'est pas représentatif du vrai code

[loufoque]

Non. Une division par 0 lève un comportement indéfini. Ça ne lève pas une exception.

Avec MSVC++, ça soulève une exception structurelle, qui est très diifférente des exceptions C++, mais c'est spécifique à cette plate-forme.

[Médinoc]

Le problème majeur, c'est que sous Visual 6, catch(...) attrapait aussi les exceptions structurelles. Cela a été aboli pour une meilleure conformité au standard.

[white_tentacle]

La nuance est peut être subtile mais le résultat est le même, cela passe (ou devrait passer) dans le catch sauf dans le cas de ma fonction "C" puisque les exceptions ne sont pas gérées par le code assembleur généré (structure de la pile ?)

compile avec /EHs à priori.

http://msdn.microsoft.com/en-us/libr...x5(VS.80).aspx

[ram-0000]

compile avec /EHs à priori.

Oui aussi.
Sinon, j'allai faire une fonction interne qui ne soit pas extern "C" avec les try/catch dedans

[Médinoc]

Une fonction peut être extern "C" et avoir les try/catch.
Par contre, une fonction extern "C" est supposée nothrow.

[koala01]

Au temps pour moi, j'avais l'idée (mais ou ai-je été la pêcher ) qu'une fonction extern C était compilée avec le compilateur... C...

Ce n'est donc que le name mangling qui assure la compatibilité, et non le code qu'elle contient

Est-ce confirmé

Si oui, je me coucherai moins bête que je ne l'étais ce matin en me levant

[Médinoc]

Je pense que c'est confirmé, vu qu'une fonction C++ extern "C" contient du code C++...

[NiamorH]

Si Visual lance une exception structurelle, et qu'il ne catch plus les exceptions structurelles depuis VC6, pourquoi dans la MSDN de 2008 je trouve ceci :

If the exception-declaration statement is an ellipsis (...), the catch clause handles any type of exception, including C exceptions and system- or application-generated exceptions such as memory protection, divide by zero, and floating-point violations.

[Médinoc]

Parce qu'en fait, ça dépend d'un réglage du compilo.

Avec le paramètre /EHsc ou /EHs il ne les catche pas, mais avec /EHa, si.

Edit: Sachant que Visual 2005 utilise /EHsc par défaut, sans doute pour de meilleures performances. Pour 2008, je ne sais pas.