Discussion :

[Aurelien.Regat-Barrel]

Donc au final, utiliser les exeption pour tout type d'erreur est un bonne methode?

Non.
http://www.parashift.com/c++-faq-lit...html#faq-17.12

Le cas typique est une classe fichier:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
File f;
try
{
    f.open( "toto.txt" );
    f.write( "Hello!" );
}
catch ( const FileNotFoundException & e )
{
    throw IOError();
}
catch ( const FileAccessError & e )
{
    throw IOError();
}

Code :

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

1
2
3
4
5
6
File f;
if ( f.open( "toto.txt" ) )
{
    return f.write( "Hello!" );
}
return false;

Si l'erreur est a destination de l'appelant de ta fonction, un simple code de retour simplifie l'utilisation. Maintenant, note que dans le 2eme cas File peut lever bad_alloc par exemple, mais comme l'appelant ne peut pas y faire grand chose, il laisse filer vers les plus hautes spheres...

[yan]

ok, merci.
Ca comme a devenir plus claire pour moi.

[loufoque]

Oui enfin dans certains cas la non existence du fichier est un cas exceptionnel

[Aurelien.Regat-Barrel]

Oui, mais ce n'est pas a la classe fichier de le décider, mais a son utilisateur. Le role d'une classe fichier est de permettre de manipuler un fichier, pas de décider s'il doit exister ou pas.

Code :

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

1
2
3
4
if ( !f.open( "mustexists.txt" ) )
{
    throw FileIsMissingException();
}

sauf si tu codes une classe FileWhichMustExists...

[Médinoc]

D'accord avec Aurelien, sauf que je serais plus du genre à y aller fonction par fonction, généralement avec un paramètre...

Code C++ :

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

	void open(const std::string &fileName, bool bThrow);

[MatRem]

Dans ce cas je ne vois pas bien l'intérêt du try/catch :

Code Aurelien.Regat-Barrel :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
File f;
try
{
    f.open( "toto.txt" );
    f.write( "Hello!" );
}
catch ( const FileNotFoundException & e )
{
    throw IOError();
}
catch ( const FileAccessError & e )
{
    throw IOError();
}

J'imagine que IOError est une classe mere de FileNotFoundException et FileAccessError, et donc qu'on peut simplifier le code comme ça :

Code :

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

1
2
3
File f;
f.open( "toto.txt" );
f.write( "Hello!" );

Et donc laisser l'appellant gérer l'erreur (par un try/catch), ce qui me semble plus pratique que la solution :

Code Aurelien.Regat-Barrel :

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

1
2
3
4
5
6
File f;
if ( f.open( "toto.txt" ) )
{
    return f.write( "Hello!" );
}
return false;

non ?

[Médinoc]

Surtout que le throw IOError() provoque la perte d'informations des exceptions précédentes...

Un avantage des plate-formes comme .Net et Java, où l'on peut chaîner les exceptions sans problème...

[JolyLoic]

Rien n'empêche les exceptions C++ d'avoir aussi une notion de chaînage d'exceptions. Ca n'a rien de compliqué à mettre en place. C'est juste que les classes standard ne l'ont pas.

[poukill]

[Mode Un Peu Hors Sujet]
En parlant de Java, je me pose la question suivante : pourquoi en Java il y a autant d'outils disponibles en standard (y compris IHM avec Swing), alors que le C++ est à la traîne (même avec l'ajout récent du TR1) ?
[/Mode Un Peu Hors Sujet]

[yan]

[Mode Un Peu Hors Sujet]
En parlant de Java, je me pose la question suivante : pourquoi en Java il y a autant d'outils disponibles en standard (y compris IHM avec Swing), alors que le C++ est à la traîne (même avec l'ajout récent du TR1) ?
[/Mode Un Peu Hors Sujet]

Sûrement pour des raison de marketing. Vendre un nouveau language sans aucun outils, c'est pas trés attirant...

[Jean-Marc.Bourguet]

[Mode Un Peu Hors Sujet]
En parlant de Java, je me pose la question suivante : pourquoi en Java il y a autant d'outils disponibles en standard (y compris IHM avec Swing), alors que le C++ est à la traîne (même avec l'ajout récent du TR1) ?
[/Mode Un Peu Hors Sujet]

Ca a ete discutte en long, en large et en profondeur, jusqu'a plus soif et ad nauseam ici. Donnons quand meme quelques pistes:
1/ Les processus d'evolution sont tres differents
2/ Les contextes dans lesquels ces processus prennent place sont differents
3/ Pour donner un point plus specifique: il y a trop d'interets deja investis dans des solutions non standards divergentes.

[poukill]

OK j'ai commencé à lire le thread, mais je pense pas avoir fini avant la semaine prochaine... Merci en tout cas pour le lien ...