C++ Traitement des exceptions et gérer les erreurs

Créer et détruire les objets

Techniquement, le domaine de la POO est celui de l’abstraction du typage des données, de l’héritage et du polymorphisme, mais d’autres questions peuvent être au moins aussi importantes.
La façon dont les objets sont créés et détruits est particulièrement importante. Où sont les données d’un objet et comment la durée de vie de l’objet est-elle gérée ? Différents langages de programmation utiliseront ici différentes philosophies. L’approche du C++ est de privilégier le contrôle de l’efficacité, alors le choix est laissé au programmeur. Pour maximiser la vitesse, le stockage et la durée de vie peuvent être déterminés à l’écriture du programme en plaçant les objets sur la pile ou dans un espace de stockage statique. La pile est une région de la mémoire utilisée directement par le microprocesseur pour stocker les données durant l’exécution du programme. Les variables sur la pile sont souvent qualifiées de variables automatiquesou de portée. La zone de stockage statique est simplement une zone fixée de la mémoire allouée avant le début de l’exécution du programme. L’utilisation de la pile ou des zones de stockage statiques met la priorité sur la vitesse d’allocation et de libération, ce qui est peut être avantageux dans certaines situations. Cependant vous sacrifiez la flexibilité parce que vous êtes obligés de connaître la quantité exacte, la durée de vie et le type des objets au moment où vous écrivez le programme. Si vous tentez de résoudre un problème beaucoup plus général, comme de la conception assistée par ordinateur, de la gestion d’entrepôt ou du contrôle de trafic aérien, c’est trop restrictif. La seconde approche est de créer des objets dynamiquement dans un emplacement mémoire appelé le tas. Dans cette approche vous ne connaissez pas, avant l’exécution, le nombre d’objets dont vous aurez besoin, leur durée de vie ou leur type exact. Ces décisions seront prises en leur temps pendant l’exécution. Si vous avez besoin d’un nouvel objet vous le créez simplement sur le tas lorsque vous en avez besoin en utilisant le mot-clé new. Lorsque vous en avez fini avec le stockage, vous devez libérer la mémoire en utilisant le mot-clé delete. Parce que le stockage est géré dynamiquement pendant l’exécution, la durée nécessaire à l’allocation sur le tas est significativement plus longue que celle pour allouer sur la pile. (Créer sur la pile consite souvent en une seule instruction du microprocesseur pour abaisser le pointeur de la pile, et une autre pour l’élever à nouveau.) L’approche dynamique donne généralement l’impression que les objets tendent à se complexifier, or les frais supplémentaires pour le stockage et la libération n’ont pas un impact important sur la création d’un objet. En plus, la plus grande flexibilité offerte est essentielle à la résolution de problèmes généraux de programmation. Il y a une autre question, cependant, c’est la durée de vie d’un objet. Si vous créez un objet sur la pile ou dans un espace de stockage statique, le compilateur détermine la durée de l’objet et peu automatiquement le détruire. Cependant, si vous le créez sur le tas, le compilateur ne connaît pas sa durée de vie. En C++, le programmeur est obligé de déterminer par programme le moment où l’objet est détruit, et effectue cette destruction en utilisant le mot-clé delete. Comme une alternative, l’environnement peut offrir un dispositif appelé garbage collector(ramasse-miettes) qui détermine automatiquement quand un objet n’est plus utilisé et le détruit. Bien sûr, écrire un programme utilisant un garbage collector est plus pratique, mais cela requiert que toutes les applications tolèrent l’existence de ce collecteur et les frais inhérents à la collecte des déchets. Ceci ne satisfait pas les conditions de conception du langage C++ et ainsi il n’en est pas fait mention, mais les collecteurs tiers existent en C++.

Traitement des exceptions : gérer les erreurs

Depuis les débuts des langages de programmation, le traitement des erreurs s’est révélé l’un des problèmes les plus ardus. Parce qu’il est difficile de concevoir un bon mécanisme de gestion des erreurs, beaucoup de langages ignorent ce problème et le délèguent aux concepteurs de bibliothèques qui fournissent des mécanismes de demi-mesure qui fonctionnent dans beaucoup de situations mais peuvent être facilement contournés, généralement en les ignorant. L’une des faiblesses de la plupart des mécanismes d’erreur est qu’ils reposent sur la vigilance du programmeur à suivre des conventions non imposées par le langage. Si les programmeurs ne sont pas assez vigilants, ce qui est souvent le cas s’ils sont pressés, ces mécanismes peuvent facilement être oubliés. La gestion des exceptions intègre la gestion des erreurs directement au niveau du langage de programmation et parfois même au niveau du système d’exploitation. Une exception est un objet qui est « émis » depuis l’endroit où l’erreur est apparue et peut être intercepté par un gestionnaire d’exception conçu pour gérer ce type particulier d’erreur. C’est comme si la gestion des exceptions était un chemin d’exécution parallèle à suivre quand les choses se gâtent. Et parce qu’elle utilise un chemin d’exécution séparé, elle n’interfère pas avec le code s’exécutant normalement. Cela rend le code plus simple à écrire car on n’a pas à vérifier constamment si des erreurs sont survenues. De plus, une exception émise n’est pas comme une valeur de retour d’une fonction signalant une erreur ou un drapeau positionné par une fonction pour indiquer une erreur – ils peuvent être ignorés. Une exception ne peut pas être ignorée, on a donc l’assurance qu’elle sera traitée quelque part. Enfin, les exceptions permettent de revenir d’une mauvaise situation assez facilement. Plutôt que de terminer un programme, il est souvent possible de remettre les choses en place et de restaurer son exécution, ce qui produit des systèmes plus robustes. Il est bon de noter que le traitement des exceptions n’est pas une caractéristique orientée objet, bien que dans les langages OO une exception soit normalement représentée par un objet. Le traitement des exceptions existait avant les langages orientés objet. La gestion des exceptions est simplement introduite et utilisée de manière superficielle dans ce volume – le Volume 2 (disponible sur www.BruceEckel.com) traite en profondeur la gestion des exceptions.

 Analyse et conception

Le paradigme de la POO constitue une approche nouvelle et différente de la programmation et beaucoup de personnes rencontrent des difficultés pour appréhender leur premier projet orienté objet. Une fois compris que tout est supposé être un objet, et au fur et à mesure qu’on se met à penser dans un style plus orienté objet, on commence à créer de « bonnes » conceptions qui s’appuient sur tous les avantages que la POO offre. Une méthode(ou méthodologie) est un ensemble de processus et d’heuristiques utilisés pour réduire la complexité d’un problème. Beaucoup de méthodes orientées objet ont été formulées depuis l’apparition de la POO. Cette section vous donne un aperçu de ce que vous essayez d’accomplir en utilisant une méthode.
Spécialement en POO, une méthodologie s’appuie sur un certain nombre d’expériences, il est donc important de comprendre quel problème la méthode tente de résoudre avant d’en adopter une. Ceci est particulièrement vrai avec le C++, qui a été conçu pour réduire la complexité (comparé au C) dans l’écriture d’un programme. Cette philosophie supprime le besoin de méthodologies toujours plus complexes. Au contraire, des méthodologies plus simples peuvent se révéler tout à fait suffisantes avec le C++ pour une classe de problèmes plus large que ce qu’elles pourraient traiter avec des langages procéduraux. Il est important de réaliser que le terme « méthodologie » est trompeur et promet trop de choses. Tout ce qui est mis en oeuvre quand on conçoit et réalise un programme est une méthode. Ca peut être une méthode personnelle, et on peut ne pas en être conscient, mais c’est une démarche qu’on suit au fur et à mesure de l’avancement du projet. Si cette méthode est efficace, elle ne nécessitera sans doute que quelques petites adaptations pour fonctionner avec le C++. Si vous n’êtes pas satisfait de votre productivité ou du résultat obtenu, vous serez peut-être tenté d’adopter une méthode plus formelle, ou d’en composer une à partir de plusieurs méthodes formelles. Au fur et à mesure que le projet avance, le plus important est de ne pas se perdre, ce qui est malheureusement très facile. La plupart des méthodes d’analyse et de conception sont conçues pour résoudre même les problèmes les plus gros. Il faut donc bien être conscient que la plupart des projets ne rentrant pas dans cette catégorie, on peut arriver à une bonne analyse et conception avec juste une petite partie de ce qu’une méthode recommande Un excellent exemple de cela est UML Distilled, de Martin Fowler (Addison-Wesley 2000), qui réduit le processus UML parfois surdimensionné à un sous ensemble utilisable.. Une méthode de conception, même limitée, met sur la voie bien mieux que si on commence à coder directement.
Il est aussi facile de rester coincé et tomber dans la « paralysie analytique » où on se dit qu’on ne peut passer à la phase suivante car on n’a pas traqué le moindre petit détail de la phase courante. Il faut bien se dire que quelle que soit la profondeur de l’analyse, certains aspects d’un problème ne se révéleront qu’en phase de conception, et d’autres en phase de réalisation, voire même pas avant que le programme ne soit achevé et exécuté. A cause de ceci, il est crucial d’avancer relativement rapidement dans l’analyse et la conception, et d’implémenter un test du système proposé.