Alors voici ce que j'en sais de mon expérience.
Perso j'utilise pas mal les exceptions, au niveau vitesse il faut savoir que c'est quasiment impossible de savoir en le regardant si un code déclenchant éventuellement une exception sera plus lent ou pas qu'un code sans exception du moins dans la mesure ou elle se déclenche pas.
Et même si elle se déclenche, il y a 2 choses à prendre en compte:
- Certains compilateurs peuvent *aplatir* certaines situations d'exceptions, changeant ainsi l'effet du throw-catch en quelque chose de moins lourd.
- Une bonne utilisation des smart pointers ou du RTTI peut facilement permettre de faire face aux fuites de mémoire qui seraient induites par un changement dans le flux d'exécution.
Cependant, c'est clair que c'est pas une mécanique de gestion appropriée pour les inner-loop et les opérations ou le risque est important dans un algo où on recherche avant tout la vitesse.
En revanche c'est excellent pour les opération IO, sockets, fichiers etc...
En fait, les exceptions sont particulièrement intéressantes du point de vue de la lisibilité lorsque vos programmes commencent à avoir des architectures complexes. Si vous avez 5-6 méthodes qui s'appellent consécutivement et que tout à coup la 6e part en erreur :
1) si vous bossez avec des valeurs de retours spécialisées, non seulement vous perdez en lisibilité mais vous devez vous balader l'erreur dans 6 "return" consécutif.
2) Si vous utilisez des patterns setError(int, std::string), vous introduirez du couplage, vous devrez gérer la remise à zéro de l'erreur et ce sera la merde dans tout scénario de concurrence non trivial.
Ce que les exceptions vous apportent ici, c'est le pouvoir de propagation et la possibilité de laisser à l'appelant le choix de ce qu'il va faire.
Si au fin fond d'une librairie vous faites un
if( !file.write("hello") )
{
cout << "erreur d'écriture";
exit(1);
}
vous avez l'air malin si on utilise votre code sans console, et si l'application voudrait récupérer de cette erreur et tenter autre chose...
Car il faut pas se leurrer, c'est souvent les couches les plus élevées d'un programme qui sont intéressées par la gestion d'erreur, c'est elles qui savent comment réagir, si on doit afficher un message, quitter l'applic, etc... car elles ont la vision du contexte. Tandis que dans le fin-fond d'une librairie, on n'a aucune vision du contexte vous m'suivez?
Pour reprendre le cas de dnob, un throwing constructor est dangereux car le destructeur n'est pas appelé si la construction échoue. Donc tout ce qui doit être déalloué dont on n'a pas trace dans les membres ne peut plus être détruit. On peut utiliser les smart pointers pour résoudre le souci mais en général il est pas mal d'éviter les opérations à exception dans le constructeur.
Pour ce qui est des exceptions systèmes, SEGFAULT, à ce que j'en sais ça n'a rien à voir avec la mécanique d'exception en c++ et ce n'est gérable que par un signal handler.
Plus ou moins toutes les erreurs qui ne sont pas balancées par un throw ne sont pas des exceptions c++ et sitôt qu'un code teste la longueur un buffer avant de décider de lever une exception, on tombe dans la gestion d'exception du langage et les mécanismes de protection de l'OS restent à l'écart.
Une dernière chose, en faveur des exceptions, on peut aussi constater que boost repose beaucoup sur les exceptions, et la plupart des développeurs de cette librairie sont très loin d'être des guignols. Pensez-y si vous avez l'impression que c'est une mauvaise pratique ou un abus du c++.
