euh, et ? c'est surtout que contrairement à Java (au pif) les exceptions ne remplacent pas une gestion d'erreurs rigoureuse et qu'elles ne devraient jamais arriver, et que quand une arrive, en général ton programme ne peut plus faire grand chose d'utile
une exception dans le constructeur du 5ème Toto d'un tableau de 10, on fait quoi ? on ne sait pas forcément dans quel état il est, les autres non plus, souvent on ne sait meme pas lequel a planté. la vie est belle...
On sait très bien ce qu'on fait parce que la norme garantie que tout objet totalement construit voit son destructeur appelé. Donc dans l'exemple que tu donne, le destructeur des 4 Toto totalement construit seront appelés ainsi que le destructeur des membres du 5ème Toto. Le destructeur du 5ème Toto ne sera pas appelé en revanche. Le tableau ne sera de toute façon pas accessible car pas totalement construit.
La seule chose à laquelle il faut faire attention c'est à la façon d'écrire le constructeur des classes qui véritablement font la gestion des ressources (smart pointer, classes RAII, handle de ressource, ...).
Je serai curieux de savoir ce que Java (ou C#) apporte comme garantie supplémentaire à ce niveau là. L'impression que j'ai c'est que là où je me repose sur le finally en Java ou C#, je m'appuie sur l'appel du destructeur en C++.
D'autre part, en C#, dans le cas de l'utilisation du using(), que se passe-t-il si une exception est levée dans le constructeur ? Et est-ce que la méthode finalize() est appelée (en C# ou en Java) lorsque le constructeur a levé une exception ?
[^] # Re: Pourquoi Mono ?
Posté par Étienne . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
euh, et ? c'est surtout que contrairement à Java (au pif) les exceptions ne remplacent pas une gestion d'erreurs rigoureuse et qu'elles ne devraient jamais arriver, et que quand une arrive, en général ton programme ne peut plus faire grand chose d'utile
une exception dans le constructeur du 5ème Toto d'un tableau de 10, on fait quoi ? on ne sait pas forcément dans quel état il est, les autres non plus, souvent on ne sait meme pas lequel a planté. la vie est belle...
On sait très bien ce qu'on fait parce que la norme garantie que tout objet totalement construit voit son destructeur appelé. Donc dans l'exemple que tu donne, le destructeur des 4 Toto totalement construit seront appelés ainsi que le destructeur des membres du 5ème Toto. Le destructeur du 5ème Toto ne sera pas appelé en revanche. Le tableau ne sera de toute façon pas accessible car pas totalement construit.
La seule chose à laquelle il faut faire attention c'est à la façon d'écrire le constructeur des classes qui véritablement font la gestion des ressources (smart pointer, classes RAII, handle de ressource, ...).
Je serai curieux de savoir ce que Java (ou C#) apporte comme garantie supplémentaire à ce niveau là. L'impression que j'ai c'est que là où je me repose sur le finally en Java ou C#, je m'appuie sur l'appel du destructeur en C++.
D'autre part, en C#, dans le cas de l'utilisation du using(), que se passe-t-il si une exception est levée dans le constructeur ? Et est-ce que la méthode finalize() est appelée (en C# ou en Java) lorsque le constructeur a levé une exception ?