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?
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.
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.
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
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.
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.
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
Wykaaa writes:
[...]
| 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
Wykaaa <wykaaa@yahoo.fr> writes:
[...]
| 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.
| 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
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 ?
On Sat, 04 Jul 2009 16:22:43 +0200, Wykaaa <wykaaa@yahoo.fr>:
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 ?
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
Gabriel Dos Reis wrote:
Wykaaa writes:
[...]
| 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 wrote:
Wykaaa <wykaaa@yahoo.fr> writes:
[...]
| 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.
| 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.
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++).
On Sun, 05 Jul 2009 05:49:54 +0200, Amrein-Marie Christophe
<xxx@freesurf.fr>:
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++).
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
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 wrote:
On Sun, 05 Jul 2009 05:49:54 +0200, Amrein-Marie Christophe
<xxx@freesurf.fr>:
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 ;)
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
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.
On Sun, 05 Jul 2009 06:52:40 +0200, Amrein-Marie Christophe
<xxx@freesurf.fr>:
Pourquoi dis tu que ça n'existe pas en C++?
Désolé, je voulais dire qu'elles n'existent pas en C.
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
Gabriel Dos Reis wrote:
Amrein-Marie Christophe writes:
| Gabriel Dos Reis wrote: | | > Wykaaa writes: | > | > [...] | > | > | 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.
Gabriel Dos Reis wrote:
Amrein-Marie Christophe <xxx@freesurf.fr> writes:
| Gabriel Dos Reis wrote:
|
| > Wykaaa <wykaaa@yahoo.fr> writes:
| >
| > [...]
| >
| > | 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.
| Gabriel Dos Reis wrote: | | > Wykaaa writes: | > | > [...] | > | > | 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.
