Reprise du message précédent :

Pas de lien, désolé.
Comme je le disais, c'est un "goto sur erreur" masqué (comme le "while" et le "for" sont des gotos conditionnels).
En C, les fonctions qui traitent les erreurs ont souvent la structure suivante :

C'est ce qu'on a trouvé de plus lisible pour centraliser la désallocation des ressources, et donc éviter la duplication de ce code. Mais tu remarqueras que cela utilise des gotos, ce qui n'est guère lisible, et rompt la structure de la fonction (les appels de fonction peuvent se trouver dans des boucles).
 
Avec un mécanisme d'exceptions, on a un code similaire, mais plus lisible :

Autre avantage : non seulement la fonction peut récupérer sur erreur, mais l'appelant peut faire de même si la fonction ne souhaite pas traiter l'erreur.

au fait, comment les exceptions sont implantes dans un langage tel que le C++ ? Lorsqu'un throw est appele, comment l'exception remonte t'elle jusqu'au block catch() correspondant ?  

 
Juste un détail pour les gens qui lisent : souvent, c'est l'ouverture de la ressource qui risque de se planter, c'est pour ça qu'on met des hiérachies de try/catch pour ne fermer que ce qui a été réllement ouvert, et pas tout en bloc.
 
 
Autre chose : la dernière fois que j'ai (vraiment) touché à du C, j'ai carrément écrit des fonctions imbriqués pour pouvoir traiter proprement les échecs d'ouvertures de ressources parceque c'était vraiment trop catastrophique (y'avait plusieurs trucs à ouvrir, traiter et fermer tout).

Le principe des exceptions, quel que soit le langage, c'est, lorsqu'une exception est levée :  

• Etape 1 : le système regarde si l'instruction qui a déclenché l'exception se trouve dans un bloc qui possède un traite-exceptions. Si oui, étape 2, sinon, étape 3.
• Etape 2 : Deux cas : si parmi les types d'exceptions que traite le bloc traite-exceptions, il y a celui de l'exception levée, on exécute ce code-là et l'erreur disparait, sinon étape 3.
• Etape 3 : S'il n'y a pas d'appelant, étape 4 ; sinon, on remonte à cet appelant et on considère l'appel comme l'instruction qui a déclenché l'exception. Etape 1.
• Etape 4 : le programme se termine, avec l'erreur "Exception non traitée" (un peu comme une assertion).

Généralement, le langage offre un mécanisme pour fabriquer une exception dans le code normal, et pour relancer une exception qu'on est en train de traiter ("raise", "throw" selon les langages).

Une autre solution, c'est d'initialiser tous ses objets/pointeurs/whatever à NULL avant d'allouer les ressources. Dans ce cas, un seul catch suffit : seules les ressources non-NULLes sont à désallouer.

D'un point de vue conceptuel :
lorsques tu entres dans un bloc try/catch, tu marques la pile.
 
Lorsque l'exception est levée, tu arrêtes le programme, tu dépile frame par frame jusqu'à trouver une marque. tu regardes la tronche du catch, s'il peut catcher ton exception, tu lui file, tu mets le pointeur d'instruction au début du catch et tu relances le programme. Sinon tu continue à remonter.
 
Normalenent, le main() est lancé dans un bloc try/catch qui peut tout catcher avec un handler par défaut (je spécule mais c'est l'idée des exceptions).

Je suis tout à fait d'accord avec le bien fondé des exceptions mais pour moi les assertions ont aussi leur place.
En effet, une exception traîtent des cas exceptionnels mais relativement normaux (une erreur quelconque qui n'est pas un bug).
Par contre, les assertions gèrent les cas qui ne peuvent (et ne doivent) pas arriver dans le programme. Elles permettent de révéler des bugs dans le code (et non pas des erreurs "normales" ).
Un programme bien écrit ne doit jamais "asserter" alors qu'il peut bien évidemment lancer des exceptions.

sauf quand t'as par exemple des descripteur de fichiers, qu'une erreur d'E/S s'est produit, vas t'en savoir lequel est fermé, lequel l'es po. et si les seuls problèmes qu'on aa avaient pour simple solution des free, ça serait du gateau. mais la plus par du tmeps on a beaucoup plus de choses à faire, des choses beaucoup plus compliquées (le tout étant de savoir ou le problème est arrivé et comment le traiter sans faire de nouvelles erreurs.

 
Argggg je peux pas, désolé mais j'ai trop bossé avec des langages fonctionnels. Je peux plus supporter les nullPointerException etc.  
 
Pour moi on en reviens à la valeur spéciale qui fait passer un message d'erreur (au C quoi).

qui est effectivemnt un code d'erreur

 
Et qui va te pêter à la gueule un jour où l'autre.

Si : free() + Réinitialisation à NULL.
Mais par contre, je t'accorde que le choix de savoir quoi faire sans déclencher de nouvelles exceptions peut être de loin beaucoup plus délicat.

re: y a pas que des problèmes de malloc dans la vie

Les NullPointerException's ont au moins un avantage : le programme ne plante jamais 3 heures plus tard. C'est donc un mal bien moindre que l'erreur qui a motivé Alload pour créer ce topic : une erreur dont on ne voit les effets -- catastrophiques -- que des dizaines voire des centaines ou milliers d'instructions plus tard.
 
Et comme l'a dit Taz, les exceptions doivent rester exceptionnelles. Une référence à NULL, si comme si tu avais un booléen accompagnant la référence pour dire "cette référence est valide/pas valide". Et il ne faut pas écrire :

mais :

L'expérience montre 70 % des bugs dans les programmes de l'industrie sont des bugs mémoires. Donc des bugs de malloc.
 
Si tu arrives à les éliminer tous, déjà, tu as fait un sacré ménage, et ton programme est d'une qualité clairement supérieure.
 
Maintenant, bien sûr que tous les bugs ne sont pas des bugs mémoire. Mais les bugs non-mémoire ont un risque infiniment plus faible de déstabiliser l'application au point de la tuer. Autrement dit, la récupération sur erreur est beaucoup plus facile et moins risquée.
 
Mais, au risque de me répéter, tant que la majorité des programmes seront écrits en C ou en C++, le problème principal et réddhibitoire du logiciel sera les bugs mémoire.

oui. par ce que les destructeur sont appelés.

Ce n'est pas ce que je voulais dire. Je ne lie aucunement exceptions et problèmes mémoire. L'un est un mécanisme à la fois puissant, souple et fin pour la récupéation sur erreur -- qu'il s'agisse d'une erreur mémoire, d'une division par zéro ou d'un serveur distant qui est tombé ; l'autre est le problème numéro 1 des logiciels dans l'industrie aujourd'hui.
 
Maintenant, les conteneurs standard sont encore un autre outil, qui permet une gestion mémoire à la fois efficace et cachant/encapsulant la principale source d'erreurs mémoire : l'usage explicite des pointeurs. Donc, oui, ta conclusion est juste : un programme qui utilise les exceptions et les conteneurs, et qui utilise aussi peu que possible les pointeurs, est nettement plus facile à rendre robuste qu'un programme C classique.
 
edit> Je ne lie pas exceptions et bugs mémoire, par contre, les conteneurs sont une réponse tout à fait appropriée aux bugs mémoire inhérents à la manipulation explicite de pointeurs.

 
Et éviter d'utiliser un langage où il y a des pointeurs ? Ça aurait l'avantage que même les parties que tu n'a pas écrites te garantissent qu'il n'y a pas de pointeur qui se balade.

Les pointeurs existent en Pascal comme en Ada, c'est donc qu'il existent des cas où on ne sait pas faire sans. D'ailleurs, c'est un type de données algorithmique.
 
Mais il y a un monde entre n'utiliser que des pointeurs au sens algorithmique du terme et mettre des pointeurs à toutes les sauces.

 
Je parlais bien entendu de pointeurs manipulables au sens du C, dans le cas général d'un identifieur d'objet, le terme général est référence, qui ne suppose pas que c'est une adresse mémoire ni la moindre relation d'ordre entre les objet (puisque pendant lontemps ça a été les index 16bits de l'objet dans la table d'objet).
 
Mais si tu veux jouer sur les mots, tu peux.
 
 
edit : dailleur en Java, Smalltalk, LISP etc. on ne peut manipuler (sémantiquement) que des références et tout le monde est content.

Moi, il me semblait précisément qu'en C, la définition même d'une variable pointeur, c'était, selon Kernighan et Ritchie en personne(s?) "une variable qui contient l'adresse d'une autre variable". Adresse mémoire, sous-entendu. Ce qui signifie que l'instruction "int* p = (int*) 0x2F652C;", qui fait directement pointer quelquepart en mémoire, est parfaitement valide.
 
Alors qu'en Java, en SmallTalk et en Lisp, il s'agit bien de références sur d'autres objets, je suis d'accord.

Oui, mais c'est beaucoup plus sophistiqué quand même:
+Destination (code de gestion) déterminée à l'exécution.
+Rebrousse chemin, simplifiant le problème de sortie.
+Destruction proprement des objets trouvés en chemin, donc libération des ressources.
+Ne parasite pas le source avec de codes de retour, valeurs réservées et tests.
 
 

Le meilleur moyen de ne pas se couper, c'est de ne pas utiliser de couteau.
C'est aussi se priver d'un outil puissant...

Ah, mais je n'ai pas dit le contraire.    
De même que le "while" et le "for", bien que fondamentalement équivalents à un goto conditionnel, sont aussi bien plus sophistiqués (tu peux leur appliquer au moins les 3 premiers avantages de ta liste). Mais remémore-toi les débats qu'il y a eu à l'époque sur le goto (notamment le fameux article de Dijkstra "Goto considered harmful" et toutes les réponses qu'il a pu avoir, y compris ""Goto considered harmful" considered harmful" ).

[citation=338151,2][nom]
Le meilleur moyen de ne pas se couper, c'est de ne pas utiliser de couteau.
C'est aussi se priver d'un outil puissant...
[/citation]
 
Le problème est : un couteau dont on a que la lame est-il vraiment l'outil adapté pour changer la couche d'un bébé ?¿? Utiliser n'importe quel outil pour faire n'importe quoi sous prétexte que qu'il y a des milieu ou il a été un jour le mieux adapté me parraît un peu douteux.
 
Je me demande d'ailleur pourquoi l'assembleur n'a plus la cote car il offre une liberté inégalée avec le programme.

C'est ce que j'ai failli répondre ce matin à un autre forumeur sur un autre topic...  

Ah mais tout à fait.
Quand on en a marre de se couper, on comprend d'autant mieux l'utilité du manche, et l'intérêt qu'il soit ergonomique.
C'est encore mieux avec une trancheuse qui est calibrée et protégée.
 
La lame de rasoir n'en reste pas moins nécessaire parfois.
 
 
Et puis d'abord en C on se coupe pas, on se tire une balle dans le pied.
 
Waow les analogies foireuses...