De l'usage des exceptions

Le
Guillaume Gourdin
Bonjour à tous,

selon ma (modeste) expérience, les exceptions en C++sont très largement sous
utilisées, et on en reste (me semble t-il) toujours à la bonne vieille
méthode du retour d'un code d'erreur. Je suis un peu surpris de cet état de
fait, les exceptions étant supposées apporter une gestion plus performantes
des erreurs. J'ai dons quelques questions: est-il vrai que les exceptions
sont sous utilisées? Quels sont vos retours d'expérience? Ou bien y a t'il
une raison plus profonde à la sous-utilisation des exceptions?

Merci!

- Guillaume -
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 11
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fabien LE LEZ
Le #19693301
On Sat, 4 Jul 2009 12:34:35 +0200, "Guillaume Gourdin" :

les exceptions en C++sont très largement sous
utilisées, et on en reste (me semble t-il) toujours à la bonne vieille
méthode du retour d'un code d'erreur.



Il y a plusieurs raisons à ça :

D'une part, les exceptions n'existent pas en C, et leur support en C++
est "récent". Du coup, les gens qui programment toujours soit en C,
soit en C++ "ancien", on du mal à s'y faire. De plus, beaucoup de
bibliothèques, écrites en C, ne gèrent pas les exceptions.

D'autre part, il n'y a pas vraiment de consensus sur l'étendue
d'utilisation des exceptions.
Certains pensent qu'il faut les réserver à des cas vraiment
exceptionnels, qui ne devraient pas se produire lors du déroulement
normal du programme. Exemple : pas assez de mémoire pour créer un
objet, tentative de prendre le cinquième élément d'un tableau qui n'en
comporte que trois, etc.
D'ailleurs, par défaut, les iostream ne lancent pas d'exception en cas
d'erreur.

Note aussi que si la fonction appelante comporte directement le code
de traitement d'erreur en cas d'échec de la fonction appelée, utiliser
un code de retour est plus facile. Les exceptions deviennent utiles
s'il faut remonter de plusieurs appels de fonctions pour trouver le
code de traitement d'erreur.
Wykaaa
Le #19694171
Fabien LE LEZ a écrit :
On Sat, 4 Jul 2009 12:34:35 +0200, "Guillaume Gourdin" :

les exceptions en C++sont très largement sous
utilisées, et on en reste (me semble t-il) toujours à la bonne vieille
méthode du retour d'un code d'erreur.



Il y a plusieurs raisons à ça :

D'une part, les exceptions n'existent pas en C, et leur support en C++
est "récent". Du coup, les gens qui programment toujours soit en C,
soit en C++ "ancien", on du mal à s'y faire. De plus, beaucoup de
bibliothèques, écrites en C, ne gèrent pas les exceptions.



Qu'entends-tu par "récent" ?
Ca existait déjà dans le C++ au moins en 1990...

D'autre part, il n'y a pas vraiment de consensus sur l'étendue
d'utilisation des exceptions.
Certains pensent qu'il faut les réserver à des cas vraiment
exceptionnels, qui ne devraient pas se produire lors du déroulement
normal du programme. Exemple : pas assez de mémoire pour créer un
objet, tentative de prendre le cinquième élément d'un tableau qui n'en
comporte que trois, etc.


L'exemple du tableau est plutôt un bug de programmation. Ce n'est pas
une situation exceptionnelle comme le "pas assez de mémoire".

D'ailleurs, par défaut, les iostream ne lancent pas d'exception en cas
d'erreur.



C'est un tort !

Note aussi que si la fonction appelante comporte directement le code
de traitement d'erreur en cas d'échec de la fonction appelée, utiliser
un code de retour est plus facile. Les exceptions deviennent utiles
s'il faut remonter de plusieurs appels de fonctions pour trouver le
code de traitement d'erreur.




Je ne suis pas d'accord avec ton dernier paragraphe. Même si c'est
directement la fonction appelante qui traite l'exception, il est
préférable d'utiliser le mécanisme d'exception plutôt qu'un code retour.
Pourquoi ?
Parce que le traitement de l'exception est isolé dans le code (catch) et
non disséminé directement derrière l'appel, ce qui mélange le cas normal
et le cas "exceptionnel".
C'est une question de méthodologie, de lisibilité et de maintenabilité.
De plus, on peut facilement changer le catch au profit de la capture
d'une exception plus générale que l'exception spécifique qu'on a
"attrapé" dans la première version d'un logiciel.
Gabriel Dos Reis
Le #19694421
Wykaaa
[...]

| C'est une question de méthodologie, de lisibilité et de maintenabilité.
| De plus, on peut facilement changer le catch au profit de la capture
| d'une exception plus générale que l'exception spécifique qu'on a
| "attrapé" dans la première version d'un logiciel.

Et il savoir apprécier le cas où un code d'erreur de retour est
préférable à une exception.

-- Gaby
Fabien LE LEZ
Le #19695761
On Sat, 04 Jul 2009 16:22:43 +0200, Wykaaa
tentative de prendre le cinquième élément d'un tableau qui n'en
comporte que trois, etc.


L'exemple du tableau est plutôt un bug de programmation.



T'es sûr ?

Imagine le cas suivant : j'ai chargé un fichier ligne par ligne dans
un vector<string>. Les spécifications de ce fichier indiquent
clairement qu'il doit contenir 5 lignes. Si le fichier est mal formé,
je ne peux qu'arrêter le programme.

Je pourrais écrire :

if (lignes.size() < 5)
throw quelque_chose;
f (lignes[4]);

Sauf que... la fonction at() fait déjà ça pour moi ! Pourquoi
réinventer la roue ?
Amrein-Marie Christophe
Le #19696501
Gabriel Dos Reis wrote:

Wykaaa
[...]

| C'est une question de méthodologie, de lisibilité et de maintenabilité.
| De plus, on peut facilement changer le catch au profit de la capture
| d'une exception plus générale que l'exception spécifique qu'on a
| "attrapé" dans la première version d'un logiciel.

Et il savoir apprécier le cas où un code d'erreur de retour est
préférable à une exception.

-- Gaby



Personnellement, depuis que j'ai touché à Java et .Net, je gère les erreurs
en C++ sous forme d'exceptions. Toujours.

C'est deux façons différentes de traiter les erreurs et on est libre de
faire comme on veut mais franchement, de mon point de vu, on a beau avoir
le choix, le code est plus propre et plus flexible avec les exceptions.

A chacun son truc.
Gabriel Dos Reis
Le #19696521
Amrein-Marie Christophe
| Gabriel Dos Reis wrote:
|
| > Wykaaa | >
| > [...]
| >
| > | C'est une question de méthodologie, de lisibilité et de mai ntenabilité.
| > | De plus, on peut facilement changer le catch au profit de la capture
| > | d'une exception plus générale que l'exception spécifiq ue qu'on a
| > | "attrapé" dans la première version d'un logiciel.
| >
| > Et il savoir apprécier le cas où un code d'erreur de retour e st
| > préférable à une exception.
| >
| > -- Gaby
|
| Personnellement, depuis que j'ai touché à Java et .Net, je gà ¨re les erreurs
| en C++ sous forme d'exceptions. Toujours.
|
| C'est deux façons différentes de traiter les erreurs et on est libre de
| faire comme on veut mais franchement, de mon point de vu, on a beau avoir
| le choix, le code est plus propre et plus flexible avec les exceptions.
|
| A chacun son truc.

Une erreur courante chez les nouveaux convertis, c'est de croire que
l'un des mécanismes est universellement supérieur à l'autre.

-- Gaby
Fabien LE LEZ
Le #19696511
On Sun, 05 Jul 2009 05:49:54 +0200, Amrein-Marie Christophe

Personnellement, depuis que j'ai touché à Java et .Net, je gère les erreurs
en C++ sous forme d'exceptions. Toujours.



En gros, tu programmes en Java tout en utilisant un compilateur C++ ?
Ça ressemble aux gens (plus nombreux) qui programment en C tout en
utilisant un compilateur C++ (et qui, pour en revenir au sujet,
n'utilisent jamais les exceptions, puisqu'elles n'existent pas en
C++).
Amrein-Marie Christophe
Le #19696561
Fabien LE LEZ wrote:

On Sun, 05 Jul 2009 05:49:54 +0200, Amrein-Marie Christophe

Personnellement, depuis que j'ai touché à Java et .Net, je gère les
erreurs en C++ sous forme d'exceptions. Toujours.



En gros, tu programmes en Java tout en utilisant un compilateur C++ ?



On pourrait dire ça oui. Tu me diras, je pousse le vice jusqu'à toujours
utiliser les commentaires style Java pour pouvoir ensuite générer la doc
développeur et je sépare les classes systématiquement dans des fichiers
différents.

Ça ressemble aux gens (plus nombreux) qui programment en C tout en
utilisant un compilateur C++ (et qui, pour en revenir au sujet,
n'utilisent jamais les exceptions, puisqu'elles n'existent pas en
C++).



Autant appliquer une méthodologie qui nous correspond ;)

Pourquoi dis tu que ça n'existe pas en C++?
Fabien LE LEZ
Le #19696591
On Sun, 05 Jul 2009 06:52:40 +0200, Amrein-Marie Christophe

Pourquoi dis tu que ça n'existe pas en C++?



Désolé, je voulais dire qu'elles n'existent pas en C.
Amrein-Marie Christophe
Le #19696581
Gabriel Dos Reis wrote:

Amrein-Marie Christophe
| Gabriel Dos Reis wrote:
|
| > Wykaaa | >
| > [...]
| >
| > | C'est une question de méthodologie, de lisibilité et de
| > | maintenabilité. De plus, on peut facilement changer le catch au
| > | profit de la capture d'une exception plus générale que l'exception
| > | spécifique qu'on a "attrapé" dans la première version d'un logiciel.
| >
| > Et il savoir apprécier le cas où un code d'erreur de retour est
| > préférable à une exception.
| >
| > -- Gaby
|
| Personnellement, depuis que j'ai touché à Java et .Net, je gère les
| erreurs en C++ sous forme d'exceptions. Toujours.
|
| C'est deux façons différentes de traiter les erreurs et on est libre de
| faire comme on veut mais franchement, de mon point de vu, on a beau
| avoir le choix, le code est plus propre et plus flexible avec les
| exceptions.
|
| A chacun son truc.

Une erreur courante chez les nouveaux convertis, c'est de croire que
l'un des mécanismes est universellement supérieur à l'autre.




Supérieur non. Mais on a tous notre façon de travailler. A l'époque ou je
codais encore sous DOS avec Turbo C++ et Topspeed C++, je comprenais rien
aux soit disant avantages des exceptions dont on parlait dans la press...
et comme ces outils ne savaient pas les gérer...

Philosophie bidon du dimanche 7h00 du mat: Autant laisser chacun choisir son
mode de fonctionnement. Entre cigales et fourmis, aucune des deux espèces
n'a disparu.
Publicité
Poster une réponse
Anonyme