Discussion :

[NoIdea]

Merci pour ces réponses, mais j'aimerais juste avoir une confirmation :

Si aucune exception est lancée lors de l'exécution, quelque soit l'endroit ou se trouve le try catch, quelque soit l'exception, la méthode par exception est toujours plus rapide que la méthode if.
Ce qui signifie donc, qu'une exception ne prend aucun temps à l'exécution, si cette exception est lancée très très rarement.

[koala01]

Merci pour ces réponses, mais j'aimerais juste avoir une confirmation :

Si aucune exception est lancée lors de l'exécution, quelque soit l'endroit ou se trouve le try catch, quelque soit l'exception, la méthode par exception est toujours plus rapide que la méthode if.

Si la gestion de l'erreur s'effectue ailleurs que dans la fonction qui appelle directement celle dans laquelle l'erreur survient.

Ce qui signifie donc, qu'une exception ne prend aucun temps à l'exécution, si cette exception est lancée très très rarement.

Si l'exception ne survient pas, tu n'a aucun temps d'exécution supplémentaire, mais tu risque malgré tout d'avoir le cout du test qui décidera (ou non) de lancer l'exception

[Astraya]

Je serais plutôt de l'avis de Loic sur ce coup là...

Oui je suis d'accord aussi avec lui, j'ai du mal m'exprimer. Si il s'agit d'une séquence d'instructions faite une seule fois, comme le chargement de fichier que tu as mentionné ou tout autre test unique, ça peut être utilisé bien entendu. Mais si une exception est lancé, si je en dis pas de bêtise, un try catch est un if-goto caché si une exception ce lance non? Si un test if échoue il ne fait aucun saut en mémoire. Je ne parle ici bien évidemment que d'un contexte ou une erreur peut arriver fréquemment, l'utilisation d'un if sera moins lourd que de récupérer l'erreur mais plus couteux si aucune erreurs ne surviens. Donc pour moi, une exception oui dans le cas ou ça n'arrivera pas souvent et ou la perte de vitesse est acceptable et non si une exception arrive souvent et ou la perte de vitesse est "inacceptable".

Si A appelle B qui appelle C qui apppelle D qui appelle E ... qui appellle Z, mais que la solution à un problème qui apparait dans Z ne se trouve que dans A, tu devra au minimum placer un test dans toutes les fonctions intermédiaires, et ce test prend malgré tout du temps.

Là aussi entièrement d'accord, mais dans le cas ou c'est à ce point imbriqué, Si A possède la solution alors il doit être aussi en mesure de pouvoir trouvé le problème, non? Ou alors c'est à Z de connaitre la solution ou de savoir ou la récupérer.

Quand on sait que le simple fait de provoquer l'affichage d'un message "j'ai pas trouvé le fichier" suffit pour éviter que l'application ne plante et pour permettre à l'utilisateur de corriger son erreur, il serait dommage de s'en priver, non, application 3D ou non

Oui, bien que le fstream et beaucoup d'autres objets du même type standrad est testable avec if non?

Mais, si tu place ta boucle dans le bloc try (au lieu de placer le bloc try dans la boucle), tu t'arrête de toutes manières... à la première exception lancée, ce qui est généralement la meilleure manière de faire

Bien sur!

[NoIdea]

Je ne dois pas avoir compris car je vois une incohérence dans vos messages :

-L'un dit, une exception dans une boucle ralentit l'exécution.
-L'autre dit une exception ne ralentit pas l'exécution tant quelle n'est pas lancée.

Autrement dit, il me semble que vous dites "un try est un if" et en même tant vous dites "un try ne ralentit pas l'exécution".

Je me trompe quelque part ?

[Nanoc]

Je me permets de rebondir sur une question qui n'a pas reçue de réponse dans ce thread.

Y-a-t'il un moyen de désactiver les exceptions sous GCC sans toucher au code ?

[Flob90]

-fno-exceptions il me semble.

[gl]

Là aussi entièrement d'accord, mais dans le cas ou c'est à ce point imbriqué, Si A possède la solution alors il doit être aussi en mesure de pouvoir trouvé le problème, non? Ou alors c'est à Z de connaitre la solution ou de savoir ou la récupérer.

Non.

Prenons le cas de l'erreur d'ouverture du fichier. La fonction appelante n'est pas en mesure de savoir à priori si l'ouverture va échouer ou non (ou tout du moins pas de manière certaine et systématique) et ce n'est certaines pas à la fonction réalisant l'ouverture du fichier de décider que faire en cas de problème et doit bien laisser le traitement de l'erreur à une fonction au dessus.

-L'un dit, une exception dans une boucle ralentit l'exécution.

Si tu t'en sers pour piloter la boucle oui. Si tu te contentes de lancer une exception en cas d'erreur dans la boucle et que cette exception remonte jusqu'à pouvoir être traitée, ça n'a pas de surcoût particulier.

L'éternel problème des questions du coût des exception est toujours de savoir ce que l'on compare.
Il est malheureusement assez fréquent de trouver des avis négatifs sur les exceptions basés sur comparaisons entre une gestion propre par exception et une gestion incorrecte des codes d'erreur ou où l'on compte le test de déclenchement de l'exception comme surcoût de l'exception alors que ce test est présent quelque soit le mécanisme de remonté de l'erreur.

[NoIdea]

Ce que j'aimerais savoir, c'est si j'ai un code comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
int main()
{
    try
    {
        CallFunc();//On apelle une fonction.
    }
    catch(...)
    {
        //Quelque chose
    }
}

Si, CallFunc n'émet jamais d'exceptions, est-il plus lent que ceci :

Code :

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

1
2
3
4
int main()
{
    CallFunc();//On apelle une fonction.
}

Bien sur, sur un seul try catch même si il y a une différence cela ne se verra pas, mais si je faisait la même chose avec une boucle while(1) autour, sans les optimisations que le compilateur peut faire, lequel serait le plus rapide ?

[jblecanard]

Je rebondis rapidement sur le point à propos des GUI 3D.

Le fait est que quand on fait de la 3D, on a notamment :
- Un scenegraph et des passes de rendus complexes, donc beaucoup de code parcouru et une pile d'appel profonde.
- Beaucoup de modes "dégradés" qui dépendent des capacités 3D de la machine de l'utilisateur.

Par conséquent, quand il y a un problème dans un rendu 3D, on préfère quand même dessiner "ce qu'on peut" plutôt que de sortir en erreur. Les modes dégradés sont prévisibles et vont fatalement avoir lieu, donc il est en effet dommage de les gérer par des exceptions qui seraient lancées à chaque rendu d'un frame. Il vaut mieux gérer cette partie avec des codes d'erreurs, mais cela n'empêche en rien d'user des exceptions dans les autres parties du projet.

[koala01]

Par conséquent, quand il y a un problème dans un rendu 3D, on préfère quand même dessiner "ce qu'on peut" plutôt que de sortir en erreur. Les modes dégradés sont prévisibles et vont fatalement avoir lieu, donc il est en effet dommage de les gérer par des exceptions qui seraient lancées à chaque rendu d'un frame. Il vaut mieux gérer cette partie avec des codes d'erreurs, mais cela n'empêche en rien d'user des exceptions dans les autres parties du projet.

Nous sommes bien d'accord là dessus...

Et cela confirme bien ce que l'on dit, à savoir que la gestion d'erreur par exception n'est pas forcément adaptée partout

Mais il faut aussi se rendre compte que la gestion du rendu n'est qu'une partie des problèmes qu'une application 3D est susceptible de rencontrer.

Nous sommes d'accord sur le fait que c'est une partie qui peut prendre énormément de place dans la conception et dans la réalisation, mais ce n'est absolument pas une raison pour qu'elle occulte tout le reste, qui sera malgré tout primordial dans la vie du projet: c'est très bien de s'organiser pour avoir un rendu agréable, mais, s'il n'y a rien à afficher... ca ne sert pas à grand chose

Or, toutes ces parties qui ne participent pas (ou du moins pas directement) au rendu peuvent provoquer des erreurs, qui peuvent mériter d'être gérées sous la forme d'exception, ne serait-ce que pour faciliter la "remontée" de l'information jusqu'à un point où il sera possible d'en assurer une gestion correcte

De plus, il reste toujours tout à fait possible de faire en sorte, au moment où l'on observe qu'une exception a été lancée, de faire en sorte d'y apporter une solution pour qu'elle ne soit plus lancée par la suite.

Tu pourrais donc parfaitement envisager, pour le rendu, de partir du rendu "idéal" et de "switcher" sur un rendu dégradé en cas d'exception.

Au final, l'exception ne serait lancée qu'au lancement de l'application, dans une période "de mise en route", le reste de l'exécution ne mettant plus le système de rendu dans une situation dans laquelle il risque de lancer l'exception survenue lors du premier passage, et l'on pourrait même envisager de sauvegarder l'état "ne lançant pas d'exception" et de le récupérer lors des lancements suivants de l'application.

En conclusion, je dirais que ton argumentation est correcte, mais que tu n'a *peut-être* pas forcément réfléchi assez loin aux alternative, sans doute parce que tu pars d'un préjugé défavorable

[jblecanard]

D'accord, mais ce n'est pas nécessairement possible car en 3D on fait rarement tout soit même.

Si tu utilises des outils pour ton rendu qui vont te renvoyer des codes d'erreurs, il se peut que tu aies besoin de faire l'appel quand même et que la fonction que tu utilises, pour laquelle tu n'as pas la main sur l'implémentation, intègre elle-même une situation dégradée et le signale au travers de son code d'erreur. Je n'ai pas d'exemple précis en tête, mais je serais pas surpris que quelques shaders aie un tel comportement.

Si tu dois rajouter la dessus tout un système qui choisit les meilleurs appels à effectuer, ça commence à devenir complexe à concevoir ! Pour un gain qui n'en vaut pas nécessairement la peine.

[koala01]

D'accord, mais ce n'est pas nécessairement possible car en 3D on fait rarement tout soit même.

Si tu utilises des outils pour ton rendu qui vont te renvoyer des codes d'erreurs, il se peut que tu aies besoin de faire l'appel quand même et que la fonction que tu utilises, pour laquelle tu n'as pas la main sur l'implémentation, intègre elle-même une situation dégradée et le signale au travers de son code d'erreur. Je n'ai pas d'exemple précis en tête, mais je serais pas surpris que quelques shaders aie un tel comportement.

Si tu dois rajouter la dessus tout un système qui choisit les meilleurs appels à effectuer, ça commence à devenir complexe à concevoir ! Pour un gain qui n'en vaut pas nécessairement la peine.

Il est clair que tu dois t'adapter à la situation dans laquelle tu te trouve... Il n'a même jamais été question d'oser remettre ce point en question

Ce qu'il est important de comprendre, c'est que, en dehors de toute circonstance propre à la situation dans laquelle tu te trouve, tu reste totalement libre du choix de la manière dont tu va gérer les erreurs, et que l'aspect le plus important à prendre en compte est la "distance" qui sépare le moment où "quelque chose" prépare une situation d'erreur (ou plutôt où l'on est en mesure d'apporter une solution) et le moment où l'erreur survient de manière effective.

Tu peux, d'ailleurs, faire en sorte que l'appel d'une fonction renvoyant un code d'erreur finisse par lancer une exception, tout comme tu peux faire en sorte qu'une fonction lançant une exception finisse par renvoyer un code d'erreur.

Certaines solutions ne seront surement pas idéales dans des situations particulières, mais rien ne t'empêche d'avoir des "binders" proches de

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
/* Cette fonction lance une exception en fonction du code
 * d'erreur obtenu
 */
void foo()
{
    int error = function_with_error_code();
    switch error
    {
        case 1:
            throw ExceptionClass1();
        case 2: 
            throw ExceptionClass2();
        case 3 : 
            throw ExceptionClass3();
        /* ... */
    }
}
/* et celle-ci renvoie un code d'erreur en fonction de l'exception 
 * qui a été lancée
 */
int bar()
{
    try
    {
        function_that_trow_exception();
    }
    catch(ExceptionClass1 &)
    {
        return 1;
    }
    catch(ExceptionClass2 &)
    {
        return 2;
    }
    catch(ExceptionClass3 &)
    {
        return 3;
    }
    return 0;
}

Toute chose étant par ailleurs égales, le surcout n'apparait que dans le cas où une erreur survient effectivement, et la principale priorité est donc de veiller, si l'erreur survient une fois, à ce qu'elle ne survienne plus par la suite

[NoIdea]

le surcout n'apparait que dans le cas où une erreur survient effectivement

En regardant sur internet, on trouve toute sorte de réponse à cette question :
Certains disent que les exceptions rallongent même s'il n'y a pas d'exceptions lancées. D'autres, comme toi disent le contraire. Si ce que tu dis est vrai, alors, j'ai tout interet à choisir une gestion par exception (si on ne trouve pas un fichier, une connection internet perdue,... 20ms ne changent pas grand chose).

Merci.

[Astraya]

Je reviens ici pour poster un technical report de 2006 sur le C++ étant sur le site open-std.org, le pdf ici:
http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

La section qui nous intéresse ici est la 5.4 notamment 5.4.2.1. Elle explique que dans certains cas, notamment temps réel, le handling d'exception est inapproprié. Je précise bien temps-réel, pour une GUI, je doute que le clic nécessite une réponse dans le millième de seconde prêt, mais pour son rendu... c'est autre choses, et encore, si c'est un GUI pour un jeu, le résultat de la vitesse de réponse d'un clic donneras raison ou pas au joueur face à son adversaire. Bref, en 2 mots: "tout dépends"

[koala01]

Je reviens ici pour poster un technical report de 2006 sur le C++ étant sur le site open-std.org, le pdf ici:
http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

La section qui nous intéresse ici est la 5.4 notamment 5.4.2.1. Elle explique que dans certains cas, notamment temps réel, le handling d'exception est inapproprié. Je précise bien temps-réel, pour une GUI, je doute que le clic nécessite une réponse dans le millième de seconde prêt, mais pour son rendu... c'est autre choses, et encore, si c'est un GUI pour un jeu, le résultat de la vitesse de réponse d'un clic donneras raison ou pas au joueur face à son adversaire. Bref, en 2 mot: "tout dépends"

D'autant plus que l'on est quand même loin des 20ms...

Cela se joue normalement en terme d'une ou deux instructions processeur, ce qui prendre à peine quelque cycles d'horloges

Quand on sait qu'un cycle d'horloge actuel est de l'ordre de la nanoseconde, et que le réflexe humain prend presque 20 milli-seconde, on constate que l'on peut déjà perdre pas mal de cycles d'horloges

Maintenant, il est vrai que trois cycles perdu 5000 fois, ca fait de nombreuses nanosecondes

[JolyLoic]

La section qui nous intéresse ici est la 5.4 notamment 5.4.2.1. Elle explique que dans certains cas, notamment temps réel, le handling d'exception est inapproprié.

Je n'ai pas relu le doc en question, mais je crois que si c'est inapproprié, ce n'est pas parce que c'est plus long. C'est simplement parce que c'est irrégulier. Sur les millions de cycles où il n'y a pas d'exception, tout s'exécutera dans un temps t0 (probablement inférieur au temps t1 d'un cycle équivalent où les exceptions sont remplacée par une gestion d'erreur à base de if). Mais le cycle où l'exception est lancée, le temps d'exécution t2 sera bien plus important.

Dans un programme classique, ce qui fait choisir les exceptions en terme de perf, c'est que :
1000000*t0 + t2 < 1000001*t1

Dans un programme temps réel, on doit avoir :
t0<spec, t1<spec, t2<spec

Et la dernière égalité n'est pas forcément respectée. De plus, simplement évaluer t2 n'est pas aisé.

[NoIdea]

En lisant le lien donné, à la section 5.4.1.2.2, il semblerait que je n'ai pas tout compris :

On entry to each try-block :

Some implementations commit changes in execution state to variables in
the scopes enclosing the try-block – other implementations use a more
sophisticated state table

Ce qui (si je comprend bien) signifie qu'il y a un cout même quand l'exception n'est pas lancée.

Ce qui ne correspond pas à :

Unless an exception is thrown, no
run-time overhead is incurred.

Ce qui serait parfait.

Exception handling implies a form of RTTI, implying some increase in code and
data size.

Est-ce que sa peut avoir une influence sur les performances ?

[NoIdea]

Si je perçois le problème dans son ensemble, les exceptions doivent être utilisées : Lorsque elles seront lancées extrêmement rarement et que l'exécutable est créé à l'aide d'un bon compilateur (celui qui utilise les tables, gcc utilise ce système ? ).

Elles sont cependant à éviter si les performances sont importantes et que l'exception peut se produire plutôt régulièrement.

Conclusion :

Exception dans des cas rares.
Exception à éviter avec un mauvais compilateur.

C'est cela ?

[Dr Dédé]

Elles sont cependant à éviter si les performances sont importantes et que l'exception peut se produire plutôt régulièrement.

Conclusion :

Exception dans des cas rares.
Exception à éviter avec un mauvais compilateur.

C'est cela ?

Le concept n'est pas la "rareté" mais bien le fait qu'il s'agisse réellement d'une "erreur". Tu ne devrais pas utiliser une exception pour contrôler le flot d'exécution normal du code, mais bien pour rapporter un cas d'exception - une erreur. Dans ce cas, les exceptions ne sont pas moins performantes que la technique archaïque de retourner un code d'erreur que l'appelant devra vérifier avec un if, un if étant loin d'être gratuit. (en fait les processeurs actuels détestent les ifs).

Par contre, pour contrôler le flot normal, il est plus performant de s'en tenir aux structures de contrôle de flot: boucles, ifs, fonctions, etc.

Il existe effectivement des situations où les exceptions ne peuvent être utilisées (dans les systèmes temps-réel), mais alors la gestion d'erreur se fait généralement en démontrant par analyse statique du code que les erreurs ne peuvent pas se produire. Ou dans les jeux vidéos, où... ça plante, et le producteur sort un patch une semaine après.

[Joel F]

Ou dans les jeux vidéos, où... ça plante, et le producteur sort un patch une semaine après.

<HS>Sauf sur console </HS>