Folco (./1064) :
cross...
Bon, en effet, vos explications m'éclairent. GC, je sais que j'ai déjà demandé, je ne sais pas pourquoi c'est toujours pas clair... Je n'arrive jamais à savoir si le compilateur est suffisamment intelligent pour ça (parce qu'il sait que mon objet crée une string, donc il devrait être capable de mettre en place tout seul le mécanisme de destruction de la string à la destruction de mon objet). Mais je sais jamais si ça se fait tout seul où si je dois lui dire... Apparemment, il sait faire à ce que tu dis.

Ben c'est simple, t'as aucun moyen de forcer la libération d'un objet que tu n'as pas alloué avec new. (C'est interdit, et ça ferait très certainement planter ton programme) La conclusion logique et que c'est donc quelqu'un d'autre qui le fait à ta place… Non ?

Bon, dans la foulée, une autre question qui m'emmerde bien (je viens de percuter ça en fait, et j'ai pas du tout codé en conséquence, plein de trucs à revoir ) :

Un objet A construit lors de sa propre construction deux objets B et C en tant que membres privés.
L'objet B se construit normallement.
La construction de C échoue et il lance une exception.
Si A n'intercepte pas l'exception, mais qu'elle est récupérée par une "catch all" général à la base du programme (genre dans main()), alors B sera perdu dans la nature ?

Se tu l'as créé avec new, alors la probabilité est en effet de 100%.

Ca veut donc dire que c'est à A d'intercepter l'exception lancée par C pour nettoyer B avant de lancer sa propre exception ?

Ouep. Si l'exception fait partie du déroulement normal de ton programme (enfin qu'on soit clair, une exception ne doit jamais être normale, mais elle peut être prévisible et on peut pouvoir en récupérer, c'est de ça que je parle ici) alors oui, tu dois nettoyer proprement. Si c'est une exception pour dire que la pile est corrompue, tu peux laisser tomber et faire crasher le programme comme il faut

Si c'est ça (en fait je vois pas autre chose ^^), ça fait bien suer, je pensais justement qu'un catch all géant permettait d'éviter des blocs try/catch un peu partout dans les classes :/

Si tu sais qu'une exception peut se produire et que tu sais que tu peux la gérer, alors tu dois la gérer oui. (Les exceptions potentielles devraient être documentées dans ton API pour plus de simplicité)
Mais un « grand catch all » ça doit juste te servir à afficher à l'utilisateur une description de pourquoi ton programme a crashé, avant de terminer l'exécution, jamais à autre chose.
Le reste, c'est de la gestion au cas par cas, et si tu n'est pas au courant que l'exception peut se produire, alors tu n'as pas à la gérer. (Ça sert à diagnostiquer les bugs aussi comme ça )