Discussion :

[Eusebe]

Bonjour à tous,

J'aimerais gérer les erreurs de mon programme à l'aide des exceptions, mais avant ça je me pose quelques questions...

Comment peut-on savoir quelles exceptions sont susceptibles d'être levées par une instruction ? Par exemple, quand je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Maclasse *ptr = new Maclasse();

, je peux avoir une exception bad_alloc. Mais est-ce que ce code pourrait en lever d'autres ? Y a-t-il un endroit où je pourrais trouver la liste exhaustive des exceptions levées "en standard" et de leurs conditions de survenue (c'est mal dit, mais je pense que vous comprenez...) ?

Faut-il toujours déclarer les exceptions qu'on laisse échapper ? Si on oublie des exceptions dans la déclaration, peut-on échapper à la fonction 'terminate()' ?

Des exceptions peuvent être levées dans le constructeur d'une classe, mais est-ce qu'on ne pourrait pas en avoir aussi dans sa liste d'initialisation ? Est-ce qu'on ne risque pas alors des fuites de mémoire ?

Merci pour vos éclaircissements

[Swoög]

Normalement, la liste d'initialisation n'est pas censée lever d'exceptions, mais dans ce cas, si effectivement l'exception est catchée hors du constructeur, tu auras une fuite de mémoire, dans la supposition où l'exception entre dans le cadre d'une fonction faisant une allocation dynamique...

Ensuite, pour avoir la liste de exceptions levées en standard, il te faut regarder dans la doc... il n'y en a pas énormément... mais il faut être bien prudent car chaque ligne du constructeur est potentiellement génératrice d'une exception différente...

Pour catcher toutes les exceptions standards, tu as

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

catch (std::exception& e) {[...]}

et pour toutes les exceptions sans distinction (mais tu ne peux pas y faire référence

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

catch(...) {[...]}

Ensuite, chaque classe déclare normalement dans sa documentation les exceptions que chaque méthode est susceptible de lever....

[loufoque]

Il suffit d'utiliser le RAII et ton code devient exception-safe.

[Eusebe]

Ok, merci pour vos réponses !
Je vais essayer d'utiliser correctement le RAII

Ensuite, pour avoir la liste de exceptions levées en standard, il te faut regarder dans la doc...

La doc dont tu parles, c'est le standard ? Ou je peux les trouver ailleurs (je n'ai pas de copie du standard) ?

Ensuite, chaque classe déclare normalement dans sa documentation les exceptions que chaque méthode est susceptible de lever....

Ca, si j'ai bien compris, c'est justement aussi ce que je dois faire dans ma bibliothèque en déclarant les exceptions que laisse échapper chaque fonction.

Bon, ben y'a plus qu'à...

[Laurent Gomila]

La doc dont tu parles, c'est le standard ? Ou je peux les trouver ailleurs (je n'ai pas de copie du standard) ?

Voir FAQ C++, pour le standard (payant) comme pour la doc de référence de la bibliothèque standard.

Ca, si j'ai bien compris, c'est justement aussi ce que je dois faire dans ma bibliothèque en déclarant les exceptions que laisse échapper chaque fonction.

Tout juste Auguste.

[Eusebe]

Merci à tous... et hop, un résolu !

[Luc Hermitte]

a- Comment peut-on savoir quelles exceptions sont susceptibles d'être levées par une instruction ? Par exemple, quand je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Maclasse *ptr = new Maclasse();

, je peux avoir une exception bad_alloc. Mais est-ce que ce code pourrait en lever d'autres ?

b- Y a-t-il un endroit où je pourrais trouver la liste exhaustive des exceptions levées "en standard" et de leurs conditions de survenue (c'est mal dit, mais je pense que vous comprenez...) ?

c- Faut-il toujours déclarer les exceptions qu'on laisse échapper ? Si on oublie des exceptions dans la déclaration, peut-on échapper à la fonction 'terminate()' ?

a-
new -> bad_alloc
constructeur -> ce que tu lêves directement ou non (niveau corps du constructeur) + ce que lêvent les constructeurs de tes attributs (niveau liste d'initialisation, explicite ou implicite)

b- Une doc de référence ? Tu est allé voir la FAQ ?

c- C'est un attrape couillon. En C++, les spécifications d'exception sont des assertions non débrayables. Je préfère encore me faire l'assert à la main pour avoir un core à analyser en mode débug, et donc investiguer quand une exception qui n'aurait pas du remonter remonte. Pour le release, je traduis au niveau où je suis capable d'en faire quoique ce soit.

Autrement la liste d'initialisation peut tout à fait la source d'une exception. D'où que le RAII est notre ami (FAQ!!). En général, on évite qu'une classe soit responsable de plus d'une seule ressource brute (pourquoi se limiter à la mémoire ?). Voir l'article sur "The big law of two" référencé dans la FAQ. Il me semble que ce cas particulier soit évoqué.

[Eusebe]

b- Une doc de référence ? Tu est allé voir la FAQ ?

Oui, oui... J'ai bien pensé au standard, mais il est pas consultable directement, donc je cherchais autre chose, mais je vais me débrouiller

c- C'est un attrape couillon. En C++, les spécifications d'exception sont des assertions non débrayables. Je préfère encore me faire l'assert à la main pour avoir un core à analyser en mode débug, et donc investiguer quand une exception qui n'aurait pas du remonter remonte. Pour le release, je traduis au niveau où je suis capable d'en faire quoique ce soit.

Donc, selon toi, si j'ai bien compris, il est préférable de décrire les exceptions remontées dans la doc que la bibliothèque plutôt que directement dans le code, avec le risque d'oublier des exceptions... c'est noté.

Autrement la liste d'initialisation peut tout à fait la source d'une exception. D'où que le RAII est notre ami (FAQ!!). En général, on évite qu'une classe soit responsable de plus d'une seule ressource brute (pourquoi se limiter à la mémoire ?). Voir l'article sur "The big law of two" référencé dans la FAQ. Il me semble que ce cas particulier soit évoqué.

Ah ? J'ai pourtant regardé la question de la FAQ qui parlait du RAII... J'y retourne de suite

[Luc Hermitte]

a- les draft suffisent.
Mais les docs de la SL vont bien aussi. D'où la FAQ pour avoir des adresses

c- Je ne suis pas très original là dessus. Je ne fais que suivre le mouvement.
Avoir un programme qui plante (en core dump ou assimilé) en mode debug à cause d'un oubli, ce n'est pas grave. C'est aussi pour cela que l'on a un mode debug : analyser des core résultant d'erreurs de programmation. Avoir le programme qui plante en mode release, ça craind. Ca ne fait pas sérieux.