exeption et performance

Citation:

---

Envoyé par Mongaulois

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:

---

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:

---

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...

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

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

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:

---

1 2 3 4

if ( !f.open( "mustexists.txt" ) ) { throw FileIsMissingException(); }

---

sauf si tu codes une classe FileWhichMustExists...:mrgreen:

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

Code:

---

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

---

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

Code:

---

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:

---

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:

---

1 2 3 4 5 6

File f; if ( f.open( "toto.txt" ) ) { return f.write( "Hello!" ); } return false;

---

non :? ?

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...

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.

[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]

Citation:

---

Envoyé par 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]

---

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

Citation:

---

Envoyé par 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]

---

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.

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