James Kanze a écrit :
je te l'accorde, mais bon comme je me trouve un peu répétitif
à qualifier de "n'importe quoi" certaines belles généralités
de Fabien, j'ai préféré ce découpage fort malhonnête.
> (Le « n'importe quoi », en fait, faisait référence à la
> pratique en Java. Surtout l'idée de vouloir utiliser une
> exception pour quelque chose comme VirtualMachineError.)
j'ai noté. l'avis me parait néanmoins bien tranché, les VMError
(out of mem, stack oveflow, ...) sont - à mon sens - des erreurs
difficiles à traiter: elles ne peuvent *pas* ne concerner que
l'appelant qui traiterait d'un simple code d'erreur (surtout
lorsqu'il n'y a pas d'appel explicite (débordement de pile)
ou que cet appel est cascadé (allocation); bien souvent ces
exceptions ne seront pas traités par le programme et seront
attrapées au plus bas niveau par la VM qui mettra fin à son
exécution; mais cela n'empêche pas un traitement custom et
la gestion de cette exception - qui donc, pour moi, est un
bon moyen de sortir / de notifier l'erreur.
James Kanze a écrit :
je te l'accorde, mais bon comme je me trouve un peu répétitif
à qualifier de "n'importe quoi" certaines belles généralités
de Fabien, j'ai préféré ce découpage fort malhonnête.
> (Le « n'importe quoi », en fait, faisait référence à la
> pratique en Java. Surtout l'idée de vouloir utiliser une
> exception pour quelque chose comme VirtualMachineError.)
j'ai noté. l'avis me parait néanmoins bien tranché, les VMError
(out of mem, stack oveflow, ...) sont - à mon sens - des erreurs
difficiles à traiter: elles ne peuvent *pas* ne concerner que
l'appelant qui traiterait d'un simple code d'erreur (surtout
lorsqu'il n'y a pas d'appel explicite (débordement de pile)
ou que cet appel est cascadé (allocation); bien souvent ces
exceptions ne seront pas traités par le programme et seront
attrapées au plus bas niveau par la VM qui mettra fin à son
exécution; mais cela n'empêche pas un traitement custom et
la gestion de cette exception - qui donc, pour moi, est un
bon moyen de sortir / de notifier l'erreur.
James Kanze a écrit :
je te l'accorde, mais bon comme je me trouve un peu répétitif
à qualifier de "n'importe quoi" certaines belles généralités
de Fabien, j'ai préféré ce découpage fort malhonnête.
> (Le « n'importe quoi », en fait, faisait référence à la
> pratique en Java. Surtout l'idée de vouloir utiliser une
> exception pour quelque chose comme VirtualMachineError.)
j'ai noté. l'avis me parait néanmoins bien tranché, les VMError
(out of mem, stack oveflow, ...) sont - à mon sens - des erreurs
difficiles à traiter: elles ne peuvent *pas* ne concerner que
l'appelant qui traiterait d'un simple code d'erreur (surtout
lorsqu'il n'y a pas d'appel explicite (débordement de pile)
ou que cet appel est cascadé (allocation); bien souvent ces
exceptions ne seront pas traités par le programme et seront
attrapées au plus bas niveau par la VM qui mettra fin à son
exécution; mais cela n'empêche pas un traitement custom et
la gestion de cette exception - qui donc, pour moi, est un
bon moyen de sortir / de notifier l'erreur.
James Kanze writes:
[...]
> > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > d'exception en cas d'erreur.
> > C'est un tort !
> Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> arriver à la fin du fichier.
À noter cependant que les IOStreams peuvent lever des
exceptions, si on le désire.
James Kanze <james.ka...@gmail.com> writes:
[...]
> > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > d'exception en cas d'erreur.
> > C'est un tort !
> Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> arriver à la fin du fichier.
À noter cependant que les IOStreams peuvent lever des
exceptions, si on le désire.
James Kanze writes:
[...]
> > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > d'exception en cas d'erreur.
> > C'est un tort !
> Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> arriver à la fin du fichier.
À noter cependant que les IOStreams peuvent lever des
exceptions, si on le désire.
James Kanze writes:
[...]
| > > D'ailleurs, par défaut, les iostream ne lancent pas
| > > d'exception en cas d'erreur.
|
| > C'est un tort !
|
| Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
| dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
| arriver à la fin du fichier.
À noter cependant que les IOStreams peuvent lever des exceptions, si on
le désire.
James Kanze <james.ka...@gmail.com> writes:
[...]
| > > D'ailleurs, par défaut, les iostream ne lancent pas
| > > d'exception en cas d'erreur.
|
| > C'est un tort !
|
| Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
| dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
| arriver à la fin du fichier.
À noter cependant que les IOStreams peuvent lever des exceptions, si on
le désire.
James Kanze writes:
[...]
| > > D'ailleurs, par défaut, les iostream ne lancent pas
| > > d'exception en cas d'erreur.
|
| > C'est un tort !
|
| Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
| dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
| arriver à la fin du fichier.
À noter cependant que les IOStreams peuvent lever des exceptions, si on
le désire.
On Jul 5, 7:01 pm, Gabriel Dos Reis wrote:
> James Kanze writes:
> [...]
> > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > d'exception en cas d'erreur.
> > > C'est un tort !
> > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > arriver à la fin du fichier.
> À noter cependant que les IOStreams peuvent lever des
> exceptions, si on le désire.
Certes. Si ça a un sens, c'est une autre question -- une
exception si le eofbit est positionné n'a jamais de sens,
On Jul 5, 7:01 pm, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
> James Kanze <james.ka...@gmail.com> writes:
> [...]
> > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > d'exception en cas d'erreur.
> > > C'est un tort !
> > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > arriver à la fin du fichier.
> À noter cependant que les IOStreams peuvent lever des
> exceptions, si on le désire.
Certes. Si ça a un sens, c'est une autre question -- une
exception si le eofbit est positionné n'a jamais de sens,
On Jul 5, 7:01 pm, Gabriel Dos Reis wrote:
> James Kanze writes:
> [...]
> > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > d'exception en cas d'erreur.
> > > C'est un tort !
> > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > arriver à la fin du fichier.
> À noter cependant que les IOStreams peuvent lever des
> exceptions, si on le désire.
Certes. Si ça a un sens, c'est une autre question -- une
exception si le eofbit est positionné n'a jamais de sens,
On 6 juil, 10:24, James Kanze wrote:
> On Jul 5, 7:01 pm, Gabriel Dos Reis wrote:
>
> > James Kanze writes:
> > [...]
> > > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > > d'exception en cas d'erreur.
> > > > C'est un tort !
> > > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > > arriver à la fin du fichier.
> > À noter cependant que les IOStreams peuvent lever des
> > exceptions, si on le désire.
>
> Certes. Si ça a un sens, c'est une autre question -- une
> exception si le eofbit est positionné n'a jamais de sens,
Tu viens de donner toi-meme un exemple ou ca a un sens: un parser
descendant. Si le parser voit eofbit alors qu'il a des regles "en
cours", c'est que le format des donnees est incorrect. Donc dans un
cas (regles terminees), le eofbit n'est pas une erreur alors que dans
l'autre cas (format invalide), c'est une erreur normalement
exceptionnelle. On peut evidement mettre le parseur dans etat special
(son propre badbit) et le retouner a tous les etages. Mais comme tu
l'as dit, c'est un cas typique ou les exceptions simplifient le code
de gestion des erreurs.
On 6 juil, 10:24, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 5, 7:01 pm, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
>
> > James Kanze <james.ka...@gmail.com> writes:
> > [...]
> > > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > > d'exception en cas d'erreur.
> > > > C'est un tort !
> > > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > > arriver à la fin du fichier.
> > À noter cependant que les IOStreams peuvent lever des
> > exceptions, si on le désire.
>
> Certes. Si ça a un sens, c'est une autre question -- une
> exception si le eofbit est positionné n'a jamais de sens,
Tu viens de donner toi-meme un exemple ou ca a un sens: un parser
descendant. Si le parser voit eofbit alors qu'il a des regles "en
cours", c'est que le format des donnees est incorrect. Donc dans un
cas (regles terminees), le eofbit n'est pas une erreur alors que dans
l'autre cas (format invalide), c'est une erreur normalement
exceptionnelle. On peut evidement mettre le parseur dans etat special
(son propre badbit) et le retouner a tous les etages. Mais comme tu
l'as dit, c'est un cas typique ou les exceptions simplifient le code
de gestion des erreurs.
On 6 juil, 10:24, James Kanze wrote:
> On Jul 5, 7:01 pm, Gabriel Dos Reis wrote:
>
> > James Kanze writes:
> > [...]
> > > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > > d'exception en cas d'erreur.
> > > > C'est un tort !
> > > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > > arriver à la fin du fichier.
> > À noter cependant que les IOStreams peuvent lever des
> > exceptions, si on le désire.
>
> Certes. Si ça a un sens, c'est une autre question -- une
> exception si le eofbit est positionné n'a jamais de sens,
Tu viens de donner toi-meme un exemple ou ca a un sens: un parser
descendant. Si le parser voit eofbit alors qu'il a des regles "en
cours", c'est que le format des donnees est incorrect. Donc dans un
cas (regles terminees), le eofbit n'est pas une erreur alors que dans
l'autre cas (format invalide), c'est une erreur normalement
exceptionnelle. On peut evidement mettre le parseur dans etat special
(son propre badbit) et le retouner a tous les etages. Mais comme tu
l'as dit, c'est un cas typique ou les exceptions simplifient le code
de gestion des erreurs.
On Jul 4, 12:34 pm, "Guillaume Gourdin" wrote:
> selon ma (modeste) expérience, les exceptions en C++sont très
> largement sous utilisées,
Ça dépend. D'après mon expérience, elles servent souvent trop.
> Quels sont vos retours d'expérience? Ou bien y a t'il une
> raison plus profonde à la sous-utilisation des exceptions?
Mon expérience, c'est, précisement, qu'elles sont sur-utilisées.
Surtout parmi les programmeurs plus jeunes.
On Jul 4, 12:34 pm, "Guillaume Gourdin" <tr...@hotmail.com> wrote:
> selon ma (modeste) expérience, les exceptions en C++sont très
> largement sous utilisées,
Ça dépend. D'après mon expérience, elles servent souvent trop.
> Quels sont vos retours d'expérience? Ou bien y a t'il une
> raison plus profonde à la sous-utilisation des exceptions?
Mon expérience, c'est, précisement, qu'elles sont sur-utilisées.
Surtout parmi les programmeurs plus jeunes.
On Jul 4, 12:34 pm, "Guillaume Gourdin" wrote:
> selon ma (modeste) expérience, les exceptions en C++sont très
> largement sous utilisées,
Ça dépend. D'après mon expérience, elles servent souvent trop.
> Quels sont vos retours d'expérience? Ou bien y a t'il une
> raison plus profonde à la sous-utilisation des exceptions?
Mon expérience, c'est, précisement, qu'elles sont sur-utilisées.
Surtout parmi les programmeurs plus jeunes.
ld writes:
> On 6 juil, 10:24, James Kanze wrote:
> > On Jul 5, 7:01 pm, Gabriel Dos Reis wrote:
> > > James Kanze writes:
> > > [...]
> > > > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > > > d'exception en cas d'erreur.
> > > > > C'est un tort !
> > > > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > > > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > > > arriver à la fin du fichier.
> > > À noter cependant que les IOStreams peuvent lever des
> > > exceptions, si on le désire.
> > Certes. Si ça a un sens, c'est une autre question -- une
> > exception si le eofbit est positionné n'a jamais de sens,
> Tu viens de donner toi-meme un exemple ou ca a un sens: un parser
> descendant. Si le parser voit eofbit alors qu'il a des regles "en
> cours", c'est que le format des donnees est incorrect. Donc dans un
> cas (regles terminees), le eofbit n'est pas une erreur alors que dans
> l'autre cas (format invalide), c'est une erreur normalement
> exceptionnelle. On peut evidement mettre le parseur dans etat special
> (son propre badbit) et le retouner a tous les etages. Mais comme tu
> l'as dit, c'est un cas typique ou les exceptions simplifient le code
> de gestion des erreurs.
Les parseurs que j'ai ecrits devaient de toute maniere gerer le cas
d'erreur de format et donner un message d'erreur comprehensible par
l'utilisateur. Faire un cas particulier pour la fin de fichier ne me semb le
pas simplifier les choses (on peut envisager une exception pour traiter
l'erreur
mais elle ne sera pas jetee par les streams
ld <Laurent.Den...@gmail.com> writes:
> On 6 juil, 10:24, James Kanze <james.ka...@gmail.com> wrote:
> > On Jul 5, 7:01 pm, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
> > > James Kanze <james.ka...@gmail.com> writes:
> > > [...]
> > > > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > > > d'exception en cas d'erreur.
> > > > > C'est un tort !
> > > > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > > > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > > > arriver à la fin du fichier.
> > > À noter cependant que les IOStreams peuvent lever des
> > > exceptions, si on le désire.
> > Certes. Si ça a un sens, c'est une autre question -- une
> > exception si le eofbit est positionné n'a jamais de sens,
> Tu viens de donner toi-meme un exemple ou ca a un sens: un parser
> descendant. Si le parser voit eofbit alors qu'il a des regles "en
> cours", c'est que le format des donnees est incorrect. Donc dans un
> cas (regles terminees), le eofbit n'est pas une erreur alors que dans
> l'autre cas (format invalide), c'est une erreur normalement
> exceptionnelle. On peut evidement mettre le parseur dans etat special
> (son propre badbit) et le retouner a tous les etages. Mais comme tu
> l'as dit, c'est un cas typique ou les exceptions simplifient le code
> de gestion des erreurs.
Les parseurs que j'ai ecrits devaient de toute maniere gerer le cas
d'erreur de format et donner un message d'erreur comprehensible par
l'utilisateur. Faire un cas particulier pour la fin de fichier ne me semb le
pas simplifier les choses (on peut envisager une exception pour traiter
l'erreur
mais elle ne sera pas jetee par les streams
ld writes:
> On 6 juil, 10:24, James Kanze wrote:
> > On Jul 5, 7:01 pm, Gabriel Dos Reis wrote:
> > > James Kanze writes:
> > > [...]
> > > > > > D'ailleurs, par défaut, les iostream ne lancent pas
> > > > > > d'exception en cas d'erreur.
> > > > > C'est un tort !
> > > > Tu rigoles, non ? Tu ne vas pas dire qu'une erreur de format
> > > > dans une entrée d'utilisateur est un cas « exceptionnel ». Ou
> > > > arriver à la fin du fichier.
> > > À noter cependant que les IOStreams peuvent lever des
> > > exceptions, si on le désire.
> > Certes. Si ça a un sens, c'est une autre question -- une
> > exception si le eofbit est positionné n'a jamais de sens,
> Tu viens de donner toi-meme un exemple ou ca a un sens: un parser
> descendant. Si le parser voit eofbit alors qu'il a des regles "en
> cours", c'est que le format des donnees est incorrect. Donc dans un
> cas (regles terminees), le eofbit n'est pas une erreur alors que dans
> l'autre cas (format invalide), c'est une erreur normalement
> exceptionnelle. On peut evidement mettre le parseur dans etat special
> (son propre badbit) et le retouner a tous les etages. Mais comme tu
> l'as dit, c'est un cas typique ou les exceptions simplifient le code
> de gestion des erreurs.
Les parseurs que j'ai ecrits devaient de toute maniere gerer le cas
d'erreur de format et donner un message d'erreur comprehensible par
l'utilisateur. Faire un cas particulier pour la fin de fichier ne me semb le
pas simplifier les choses (on peut envisager une exception pour traiter
l'erreur
mais elle ne sera pas jetee par les streams
Bonjour.
"Guillaume Gourdin" a écrit dans le message
de news 4a4f3042$0$30992$
> 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?
En complément aux arguments de Fabien Le Lez, en lisant du code C++
utilisant des exceptions, on voit souvent des choses aussi lourdes que
risquées, qui peuvent donc "discréditer" les exceptions aux yeux de
certains.
Lancer une exception implique de la construire, donc il vaut mieux que ce tte
partie-là soit garantie.
Il n'est pas rare de voir des exceptions créées par un new, et pour f aire
bonne mesure, on insère tout un tas de diagnostics dedans sous forme de
strings...
Tout ça pour traiter un incident tels qu'un échec d'allocation de m émoire ?
Il doit bien y avoir des gens que ça ennuie...
Ensuite, comment passe-t-on cette exception (que "throwe"-t-on) ?
Par adresse, référence ou par copie ?
La copie est plus naturelle, mais elle implique effectivement de copier t out
ça (donc de mouliner intérieurement du new et du delete).
Reste à voir ce qu'on en fait à la fin (le catch).
Si le système d'exceptions est bien fait, d'une part on a une hiérarc hie
bien claire permettant de cascader les catch spécifiques et de se passe r du
catch-all (sauf pour faire un cleanup intermédiaire suivi d'un rethrow) .
D'expérience, souvent on voit un catch-all avec dedans un printf("oh zu t, ça
a foiré") suivi de return(ERROR).
Généralement on est bien embêté parce qu'on se tape pour l'occasi on une
librairie plus ou moins exotique et on n'a pas trop le temps de creuser s on
fonctionnement intime (c'est même ce qu'on veut éviter - on a la pres sion
bien sûr):
- Pour le détail des causes d'échec possibles, normalement, on regard e les
retours de la fonction appelée, et on fait un switch avec un default...
- Pour une exception, ça peut venir de plus profond et donc c'est assez
obtus. On ne veut pas en oublier une parce que ça conduit à un planta ge et
c'est pas vendeur. Et ça peut arriver par la suite avec une nouvelle ve rsion
de ladite librairie. D'où le choix du catch-all équivalent du défau lt...
Et donc le sort de l'exception elle-même, on s'en désintéresse (ce qui en
soi "justifie" le passage par copie, car alors on peut espérer que le
destructeur prenne en charge tout ce qui doit l'être).
Moi j'aime bien les exceptions passées par adresse avec une méthode
Release() dedans, et je n'ai jamais de memory leak avec ça, mais je sui s un
cas...
Ce qui est amusant, c'est que l'usage des exceptions devrait permettre de
démonter proprement une tentative d'opération, pour laisser au proces s
maître une chance de corriger la situation (libérer des ressources pa r
exemple) et réessayer.
Moi j'aime pas trop les logiciels qui disent "au
secours, j'y arrive pas", de plus je fais dans le process automatisé, a lors
souvent il n'y a personne pour lire le message.
En général, on va seulement sortir un message "désolé ça a foir é" puis
avorter. Très souvent, la cause précise de l'erreur n'est pas remont ée
jusque-là.
Pour faire ça, il faudrait que la nomenclature des erreurs de chaque
sous-librairie soit définie (et figée) et intégrée dans la nomenc lature de
la librairie qui l'utilise, etc.
jusqu'au process maître. Il faudrait aussi
pouvoir retourner un contexte assez détaillé dans la même démarch e
encyclopédique. Il faudrait ensuite que process maître ait une strat égie
correctrice pour chaque cas recensé.
En général on ne se donne pas cette peine, ou on n'a pas de doc utili sable
pour les insides, et donc la mission de diagnostic détaillé de l'exce ption
devient presque inutile (tout au plus on ramène le complément du mess age
d'erreur à afficher pour faire plus humain "erreur système lors de l' accès
à: ujk35585.dat").
Ne reste que la lourdeur apparente du mécanisme d'exception par rapport à un
bon vieux return(code), spécialement si on dispose d'un enum de valeurs
génériques (ou l'équivalent en #define) dans un header global (beu âârk).
Bonjour.
"Guillaume Gourdin" <tr...@hotmail.com> a écrit dans le message
de news 4a4f3042$0$30992$426a7...@news.free.fr
> 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?
En complément aux arguments de Fabien Le Lez, en lisant du code C++
utilisant des exceptions, on voit souvent des choses aussi lourdes que
risquées, qui peuvent donc "discréditer" les exceptions aux yeux de
certains.
Lancer une exception implique de la construire, donc il vaut mieux que ce tte
partie-là soit garantie.
Il n'est pas rare de voir des exceptions créées par un new, et pour f aire
bonne mesure, on insère tout un tas de diagnostics dedans sous forme de
strings...
Tout ça pour traiter un incident tels qu'un échec d'allocation de m émoire ?
Il doit bien y avoir des gens que ça ennuie...
Ensuite, comment passe-t-on cette exception (que "throwe"-t-on) ?
Par adresse, référence ou par copie ?
La copie est plus naturelle, mais elle implique effectivement de copier t out
ça (donc de mouliner intérieurement du new et du delete).
Reste à voir ce qu'on en fait à la fin (le catch).
Si le système d'exceptions est bien fait, d'une part on a une hiérarc hie
bien claire permettant de cascader les catch spécifiques et de se passe r du
catch-all (sauf pour faire un cleanup intermédiaire suivi d'un rethrow) .
D'expérience, souvent on voit un catch-all avec dedans un printf("oh zu t, ça
a foiré") suivi de return(ERROR).
Généralement on est bien embêté parce qu'on se tape pour l'occasi on une
librairie plus ou moins exotique et on n'a pas trop le temps de creuser s on
fonctionnement intime (c'est même ce qu'on veut éviter - on a la pres sion
bien sûr):
- Pour le détail des causes d'échec possibles, normalement, on regard e les
retours de la fonction appelée, et on fait un switch avec un default...
- Pour une exception, ça peut venir de plus profond et donc c'est assez
obtus. On ne veut pas en oublier une parce que ça conduit à un planta ge et
c'est pas vendeur. Et ça peut arriver par la suite avec une nouvelle ve rsion
de ladite librairie. D'où le choix du catch-all équivalent du défau lt...
Et donc le sort de l'exception elle-même, on s'en désintéresse (ce qui en
soi "justifie" le passage par copie, car alors on peut espérer que le
destructeur prenne en charge tout ce qui doit l'être).
Moi j'aime bien les exceptions passées par adresse avec une méthode
Release() dedans, et je n'ai jamais de memory leak avec ça, mais je sui s un
cas...
Ce qui est amusant, c'est que l'usage des exceptions devrait permettre de
démonter proprement une tentative d'opération, pour laisser au proces s
maître une chance de corriger la situation (libérer des ressources pa r
exemple) et réessayer.
Moi j'aime pas trop les logiciels qui disent "au
secours, j'y arrive pas", de plus je fais dans le process automatisé, a lors
souvent il n'y a personne pour lire le message.
En général, on va seulement sortir un message "désolé ça a foir é" puis
avorter. Très souvent, la cause précise de l'erreur n'est pas remont ée
jusque-là.
Pour faire ça, il faudrait que la nomenclature des erreurs de chaque
sous-librairie soit définie (et figée) et intégrée dans la nomenc lature de
la librairie qui l'utilise, etc.
jusqu'au process maître. Il faudrait aussi
pouvoir retourner un contexte assez détaillé dans la même démarch e
encyclopédique. Il faudrait ensuite que process maître ait une strat égie
correctrice pour chaque cas recensé.
En général on ne se donne pas cette peine, ou on n'a pas de doc utili sable
pour les insides, et donc la mission de diagnostic détaillé de l'exce ption
devient presque inutile (tout au plus on ramène le complément du mess age
d'erreur à afficher pour faire plus humain "erreur système lors de l' accès
à: ujk35585.dat").
Ne reste que la lourdeur apparente du mécanisme d'exception par rapport à un
bon vieux return(code), spécialement si on dispose d'un enum de valeurs
génériques (ou l'équivalent en #define) dans un header global (beu âârk).
Bonjour.
"Guillaume Gourdin" a écrit dans le message
de news 4a4f3042$0$30992$
> 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?
En complément aux arguments de Fabien Le Lez, en lisant du code C++
utilisant des exceptions, on voit souvent des choses aussi lourdes que
risquées, qui peuvent donc "discréditer" les exceptions aux yeux de
certains.
Lancer une exception implique de la construire, donc il vaut mieux que ce tte
partie-là soit garantie.
Il n'est pas rare de voir des exceptions créées par un new, et pour f aire
bonne mesure, on insère tout un tas de diagnostics dedans sous forme de
strings...
Tout ça pour traiter un incident tels qu'un échec d'allocation de m émoire ?
Il doit bien y avoir des gens que ça ennuie...
Ensuite, comment passe-t-on cette exception (que "throwe"-t-on) ?
Par adresse, référence ou par copie ?
La copie est plus naturelle, mais elle implique effectivement de copier t out
ça (donc de mouliner intérieurement du new et du delete).
Reste à voir ce qu'on en fait à la fin (le catch).
Si le système d'exceptions est bien fait, d'une part on a une hiérarc hie
bien claire permettant de cascader les catch spécifiques et de se passe r du
catch-all (sauf pour faire un cleanup intermédiaire suivi d'un rethrow) .
D'expérience, souvent on voit un catch-all avec dedans un printf("oh zu t, ça
a foiré") suivi de return(ERROR).
Généralement on est bien embêté parce qu'on se tape pour l'occasi on une
librairie plus ou moins exotique et on n'a pas trop le temps de creuser s on
fonctionnement intime (c'est même ce qu'on veut éviter - on a la pres sion
bien sûr):
- Pour le détail des causes d'échec possibles, normalement, on regard e les
retours de la fonction appelée, et on fait un switch avec un default...
- Pour une exception, ça peut venir de plus profond et donc c'est assez
obtus. On ne veut pas en oublier une parce que ça conduit à un planta ge et
c'est pas vendeur. Et ça peut arriver par la suite avec une nouvelle ve rsion
de ladite librairie. D'où le choix du catch-all équivalent du défau lt...
Et donc le sort de l'exception elle-même, on s'en désintéresse (ce qui en
soi "justifie" le passage par copie, car alors on peut espérer que le
destructeur prenne en charge tout ce qui doit l'être).
Moi j'aime bien les exceptions passées par adresse avec une méthode
Release() dedans, et je n'ai jamais de memory leak avec ça, mais je sui s un
cas...
Ce qui est amusant, c'est que l'usage des exceptions devrait permettre de
démonter proprement une tentative d'opération, pour laisser au proces s
maître une chance de corriger la situation (libérer des ressources pa r
exemple) et réessayer.
Moi j'aime pas trop les logiciels qui disent "au
secours, j'y arrive pas", de plus je fais dans le process automatisé, a lors
souvent il n'y a personne pour lire le message.
En général, on va seulement sortir un message "désolé ça a foir é" puis
avorter. Très souvent, la cause précise de l'erreur n'est pas remont ée
jusque-là.
Pour faire ça, il faudrait que la nomenclature des erreurs de chaque
sous-librairie soit définie (et figée) et intégrée dans la nomenc lature de
la librairie qui l'utilise, etc.
jusqu'au process maître. Il faudrait aussi
pouvoir retourner un contexte assez détaillé dans la même démarch e
encyclopédique. Il faudrait ensuite que process maître ait une strat égie
correctrice pour chaque cas recensé.
En général on ne se donne pas cette peine, ou on n'a pas de doc utili sable
pour les insides, et donc la mission de diagnostic détaillé de l'exce ption
devient presque inutile (tout au plus on ramène le complément du mess age
d'erreur à afficher pour faire plus humain "erreur système lors de l' accès
à: ujk35585.dat").
Ne reste que la lourdeur apparente du mécanisme d'exception par rapport à un
bon vieux return(code), spécialement si on dispose d'un enum de valeurs
génériques (ou l'équivalent en #define) dans un header global (beu âârk).
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.
-- Gaby
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
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.
-- Gaby
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.
-- Gaby
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.
-- Gaby