Re: Pas de fumée sans feu

En effet, je compare le C (avec ni exceptions ni destructeurs) avec le C++ (avec exceptions et destructeurs). Voyons la solution intermédiaire ou on aurait droit aux destructeurs mais pas aux exceptions.

Ok, on passe de:

 faire_un_truc();

à:

 if (faire_un_truc())
 return;

En admettant qu'on enlève les accolades pour gagner un maximum, on est quand même à 50% des lignes qui ne sont là que pour la gestion d'erreur. Et ça c'est dans un code simple ou il n'y a pas de boucles ou autres structures de contrôle compliquées.

Mais, si on écrit le code comme ça, au-delà du bête calcul sur le nombre de lignes utiles, tout le code qui fait des trucs est "caché" dans des if() qui vérifient si les fonctions ont fonctionné. Et là on est dans un cas ou la fonction retourne juste un bool pour dire si elle a fonctionné. Mettons qu'on veut par exemple ouvrir un fichier.

Version C++ avec exceptions et destructeurs:

 void OuvrirFichier() {
 Fichier leFichier;
 }

Si ça marche pas, la fonction lève une exception.

Version C sans rien:

 void OuvrirFichier() {
 Fichier* leFichier = open();
 if (leFichier == NULL)
 return;
 close(leFichier);
 }

Version C++ sans les exceptions:

 void OuvrirFichier() {
 Fichier leFichier();
 if (!leFichier.Ouvrir())
 return;
 }

Et ça c'est juste en regardant une fonction de très près. La classe ou structure Fichier va être plus compliquée: il faut une méthode Ouvrir qui retourne une erreur, il faut un destructeur qui vérifie si le fichier est vraiment ouvert avant de le fermer.

Et là on a toujours une seule ressource dans cette fonction. Quand il y en a 2 ou plus, la complexité de la gestion d'erreur va augmenter. Il y a le risque d'oublier un cas d'erreur et de ne pas mettre un if là ou il faudrait, et de se retrouver avec un objet dans un état invalide (on peut avoir un objet Fichier qui ne correspond pas à un vrai fichier, soit parce qu'on n'a pas encore appelé la méthode Ouvrir, soit parce que la méthode a rencontré une erreur).