Discussion :

[yan]

Bonjour,
est il vrai que les exceptions plombe les performance d'un code?

merci

[ZaaN]

je sais pas exactement, mais on peut penser que oui car instruction en plus = temps en plus... Mais bon c'est pas non plus un calcul matricielle...

mais meme si c'était faux, un code qui devrait générer des exceptions et qui ne le fais pas, ne sers pas a grand choses à mon avis...

[Jean-Marc.Bourguet]

En gros, il y a differentes techniques pour implementer les exceptions. Elles offrent des compromis differents entre "surcout du a la possibilite d'avoir des exceptions quand il n'y a pas d'exception" et "cout de l'exception quand elle est presente". Une technique en particulier permet d'avoir un surcout en l'absence d'exception quasiment nul (des effets indirects sur les optimisations).

Certains OS ont aussi une notion d'exception. Lier les exceptions du C++ a celle de l'OS a alors des avantages -- compatibilite interlangage plus forte par exemple -- mais aussi des inconveniants -- on ne peut pas utiliser le compromis qu'on voudrait, parfois il existe pour le C++ des methodes qui sont meilleures sur les deux tableaux.

Naturellement, il faut comparer le cout des exceptions avec celui des alternatives qui ne sont pas gratuites non plus.

[yan]

mais meme si c'était faux, un code qui devrait générer des exceptions et qui ne le fais pas, ne sers pas a grand choses à mon avis...

Ma question et pour la gestion d'erreur dans mes class. Comme il y as plusieurs philosophie de gestion d'erreur, je me demandé si les exeption sont lent ou non.

[Aurelien.Regat-Barrel]

Tu as tant d'erreurs exceptionnelles que ca pour que les exceptions aient un impact significatif sur les performances de ton logiciel ?
http://gamearchitect.net/Articles/Ex...rrorCodes.html

[yan]

Tu as tant d'erreurs exceptionnelles que ca pour que les exceptions aient un impact significatif sur les performances de ton logiciel ?

C'est plus pour de la culture générale.
Avant de dire "les exeptions c'est cool", c'est bien de le savoir pourquoi. Et quand se sont les perf (lancer de rayon, traitement image ...) qui rentre en jeux, ça peut jouer sur la philosophie utilisé pour les erreurs.

merci pour le lien

[loufoque]

Voir ce fil très poussé sur comp.lang.c++.moderated
http://groups.google.com/group/comp....4c9b3e3509403/

Certaines implémentations n'ont aucun coût en performance dans le cas où aucune erreur ne survient (quand aucune exception n'est levée).
Ce qui signifie donc que c'est plus performant que des if/else et valeurs de retour dans ce cas.

Une technique en particulier permet d'avoir un surcout en l'absence d'exception quasiment nul (des effets indirects sur les optimisations).

D'après le thread que je viens de mentionner, on peut même avoir un surcoût parfaitement nul, du moins en temps d'exécution.

[yan]

merci pour les reponses

[Luc Hermitte]

J'étais tombé sur cela http://gamearchitect.net/Articles/Ex...rrorCodes.html
qui est une approche assez pratique et ciblée.

À l'occasion, je lirai le fil sur clc++m, merci pour le lien.

[koala01]

Salut,

Cela ne fera sans doute pas avancer le débat, mais je me permets de vous livrer le fruit de ma réflection... Meme s'il est relativement simpliste en son genre.

En toute logique, une exception est lancée quand un événement qui n'aurait pas du arriver - et ce, quelle que soit la raison - survient.

Le résultat direct, c'est que l'état dans lequel se trouve l'application ne correspond plus à l'état dans lequel elle est sensée se trouver...

Si l'application ne retrouve pas rapidement un état normal, cela pourra mener à des catastrophes, que ce soit du fait d'aberrations de résultats ou du fait du plantage pur et simple de l'application.

Des lors, et meme si le fait de lancer une exception - et sans doute aussi de la gérer - venait à couter énormément de temps, n'est il pas sensé d'estimer préférable de prendre le temps qu'il faut pour que l'application retrouve un état correct

Maintenant, je n'ai pris en compte que la perte de temps encourrue par le fait qu'une exception survienne... Et je présumes que, la question portait sur les pertes de performances dues au fait de la traquer... et sans doute, car c'est la regle générale espérée, quand elles ne surviennent justement pas

[Aurelien.Regat-Barrel]

Moi aussi j'ai pas mal réfléchi et me suis beaucoup documenté sur le sujet a un moment
Les exceptions ne sont qu'un mécanisme de transport des erreurs. J'étais tombé sur un excellent article débatant autour de ca:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
std::exception test1()
{
    if ( error ) return std::exception( "erreur" );
}
 
#define ERROR 1
void test2()
{
    if ( error ) throw ERROR;
}

Une classe exception peut etre utilisée comme code de retour, et un code d'erreur comme exception...

La vraie question qu'il faut se poser est : qui va traiter mon erreur ? Si l'appelant de la fonction est le plus a meme de réagir a l'erreur, un code de retour est préférable. Sinon, une exception peut etre judicieuse.
Pour moi, les codes de retour sont le chemin des erreurs classiques attendues, et les exceptions un mécanisme d'erreur parallele, plus grave, moins prévisible et souvent difficile a résoudre.

[poukill]

La vraie question qu'il faut se poser est : qui va traiter mon erreur ? Si l'appelant de la fonction est le plus a meme de réagir a l'erreur, un code de retour est préférable. Sinon, une exception peut etre judicieuse.

Il y a, je pense, des cas où l'appelant peut être prévenu par un mécanisme d'exception.
Dans un de mes modules récemment, je devais récupérer un fichier sur un serveur, le décompresser si nécéssaire (car tous les fichiers n'étaient pas compressés), puis appliquer des traitements dessus...
J'ai choisi la méthode de:
1) Tenter la décompression avec Boost::gzip
2) Si OK tant mieux, on continue. Sinon boost lance une exception de mauvais format d'en-tête. L'exception est attrapée puis relancée pour que l'appelant l'attrappe à son tour.
3) L'appelant sait alors que le fichier n'est pas compressé et peut donc travailler directement dessus!

Parfois, la meilleure méthode pour savoir si on peut faire quelquechose, c'est de la tenter. (cf inversion de matrices !)

[nikko34]

2) Si OK tant mieux, on continue. Sinon boost lance une exception de mauvais format d'en-tête. L'exception est attrapée puis relancée pour que l'appelant l'attrappe à son tour.

pourquoi l'attrapper si c'est pour la relancer après alors que c'est le comportement par défaut? A moins qu'il n'y ait un traitement spécifique..

[Alp]

Pour qu'elle soit attrappée par le code qui appelle la fonction qui vient de l'attrapper.

[loufoque]

Les exceptions n'ont pas besoin d'être appelées puis relancées pour être propagées à l'appelant.
C'est tout l'intérêt.

[poukill]

Euh... ça me ferait mettre un bloc try{ } sans catch dans la fonction appelé.
Le bloc catch serait uniquement dans la fonction appelante c'est bien ça?

[Laurent Gomila]

Euh... ça me ferait mettre un bloc try{ } sans catch dans la fonction appelé.
Le bloc catch serait uniquement dans la fonction appelante c'est bien ça?

Pas besoin de try tout seul (d'ailleurs ça n'aurait aucun sens), l'exception remontera toute seule comme une grande jusqu'au premier catch correspondant.

[poukill]

Bon...
Encore une boulette de Poukill !

Merci Laurent!

[koala01]

En fait, tu ne dois mettre un bloc catch (et son try correspondant) que si tu veux/dois gérer quelque en cas d'exception, et que cette gestion ne peut pas etre remise plus tard...

Ainsi, il se peut que, dans l'ordre d'appel des fonctions, tu ne dispose pas tout de suite des informations nécessaire à la gestion de l'exception

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
void fonct1()
{
    /* ce n'est que dans fonct1 qu'on peut traiter l'exception */
    try
    {
        fonct2();
    }
    catch(ton_exeption &e)
    {
        /* traitement de l'exeption */
    }
}
void fonct2()
{
    /* fonct2() n'a pas tous les éléments pour traiter l'exeption */
    fonct3();
}
void fonct3()
{
    /* C'est ici qu'on décide de lancer l'exeption */
    if (a==0)
        throw ton_exeption;
}

Par contre, il se peut que aussi bien fonct3 que fonct2 doivent prendre en charge *une partie* de la gestion de l'exeption et que le système ne revienne dans un état normal qu'apres que fonct1 aie pris en charge la fin de la gestion de l'exeption...

A ce moment là, cela devient:

Code :

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

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
33
34
35
36
37
38
39
40
41
 
void fonct1()
{
    try
    {
        fonct2();
    }
    catch(exept2 &e)
   {
        /* fin du traitement de l'exeption */
   }
}
void fonct2()
{
    try
    {
        fonct3();
    }
    catch(exeption &)
    {
         /* partie du traitement */
         /* on relance l'exeption apres traitement, et rien n'oblige à 
          * relancer la meme exeption ;) */
         throw exept2(/*...*/);
    }
}
void fonct3()
{
    try
    {
        /* c'est ici que l'exeption "primaire" survient
        if(a==0)
            throw exeption(/*...*/);
    }
    catch(exeption &e)
    {
        /*fonct3 peut gérer une partie de l'exeption... et la relancer pour
         *la fonction appelante */
        throw e;
    }
}

Et bien sur, entre ces deux extrème, il y a toutes les variations possible

[yan]

Donc au final, utiliser les exeption pour tout type d'erreur est un bonne methode?
ou faut 'il laisser les execptions au cas grave, et faire des retour d'erreur pour le reste?
ou c'est au choix?