L'expression "Gérer une exception" est elle à prendre au pied de la lettre ?

Bonjour !
L éxecution d'un bloc "try" est elle plus lente que celle du meme bloc non préfixé en cas de non lancement d'exception ?
Si non est il commun que le mecanisme des exceptions soit utilisé de manière locale afin d'éviter de tester de manière systematique la possibilité qu un truc super-rare n'arrive ?
Hmmm est ce son role finalement en deça de la propriete magique de remontage de pile d appel ?
J'ai la bizarre impression de trouver que l'eau ca mouille mais bon il n y a pas de question idiote il parait.

Citation:

---

Envoyé par BaygonV

Bonjour !
L éxecution d'un bloc "try" est elle plus lente que celle du meme bloc non préfixé en cas de non lancement d'exception ?
Si non est il commun que le mecanisme des exceptions soit utilisé de manière locale afin d'éviter de tester de manière systematique la possibilité qu un truc super-rare n'arrive ?
Hmmm est ce son role finalement en deça de la propriete magique de remontage de pile d appel ?
J'ai la bizarre impression de trouver que l'eau ca mouille mais bon il n y a pas de question idiote il parait.

---

Plusieurs réponses

1) oui, un bloc try qui ne lance pas d'exception est probablement plus lent qu'un bloc équivalent sans try. D'autant plus que les programmes qui plantent sont souvent très rapides.

2) dès lors qu'on met un try-catch, on est dans le domaine du local. SInon, on ne met pas de try-catch et on apprécie la pleine vigueur de la fonction abort() qui est appelée dès lors qu'une exception n'est pas récupérée dans un programme. Donc, de fait, le mécanisme des exceptions est systématiquement utilisé de manière locale. Et il sert effectivement à ne pas écrire de code de traitement d'erreur un peu partout, ce qui au final permet de nettement simplifier le code. Bien sûr, ça vient aussi avec un défaut ennuyeux : le code peut jumper dans un handler d'exception de manière assez impromptue, et ce n'est guère visible lorsqu'on le lit. Du coup, les exceptions permettent d'un coté de simplifier le code, et de l'autre rende sa lecture et sa compréhension plus complexe - a moins qu'on assortisse le code d'avertissement du style "ici, on ne traite pas de code d'erreur. On les disperse, on les éparpille façon puzzle. Et on récupère tout ça dans des handler d'exception". Bien sûr, on peut faire plus sain comme commentaire. L'idée est que si il est connu que le code lance et traite des exceptions, alors sa lecture est quand même simplifiée par rapport à "un coup je traite des codes d'erreurs, un autre coup je traite des exceptions".

3) c'est à toi de leur donner un rôle. Par défaut, les exception n'ont pas de rôle prédéfini. Charge à toi de leur en trouver un qui allie élégance, efficacité et sécurité.

4) oh, je te rassure. Il semblerait que les exceptions soient l'une des choses les plus complexe à appréhender en ce bas monde.

Citation:

---

Envoyé par Emmanuel Deloget

1) oui, un bloc try qui ne lance pas d'exception est probablement plus lent qu'un bloc équivalent sans try.

---

Sous Unix la technique habituelle (au moins celle demandée par l'ABI commune, et d'autres ABI utilisaient la même technique avant, elle était déjà utilisée dans d'autres langages avant que le C++ n'ait des exceptions) fait qu'avoir un bloc try ou pas s'il n'y a pas d'exception n'a un coût qu'indirect (le code devrait être presque le même, il y a des optimisations qui ne peuvent pas traverser les limites du blocs et des entrées supplémentaires dans des tables et donc une occupation plus grande de la mémoire et un risque de résonance de cache -- mais il y aussi une chance que ça en supprime).

Ma compréhension est que sous Windows -- mais je ne connais Windows que de seconde main -- la technique habituelle est de s'interfacer avec un mécanisme d'exception aussi utilise par l'OS et qui fait que l’entrée et la sortie d'un bloc try ont un coût fixe, indépendamment du fait que des exceptions sont jetées ou pas.

Quelques réponses...

À ma connaissance, sur x86, un bloc try a le même coût qu'un bloc contenant une ou plusieurs variables avec destructeur (les deux se basant en fait sur le même mécanisme sous-jacent pour s'assurer que les destructeurs sont appelés en cas d'exception).

Seul un niveau d’imbrication n'ayant ni l'un ni l'autre ne paye pas cette "taxe".