Deutsch English Français Italiano |
<ue16dc$35qrj$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" <rosen@adalog.fr> Newsgroups: fr.comp.lang.ada Subject: Re: To except or not to except ? Date: Fri, 15 Sep 2023 10:59:24 +0200 Organization: Adalog Lines: 48 Message-ID: <ue16dc$35qrj$1@dont-email.me> References: <ue14pj$kj$1@shakotay.alphanet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 15 Sep 2023 08:59:24 -0000 (UTC) Injection-Info: dont-email.me; posting-host="61b76118c10e23bc1a63081c4eb4c566"; logging-data="3337075"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19eBV9vwsdtsQRnVyiLCSsU" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Cancel-Lock: sha1:DpR3GE8ShC4UYR00CxQyBM5vZdQ= Content-Language: en-US, fr In-Reply-To: <ue14pj$kj$1@shakotay.alphanet.ch> Bytes: 3234 Le 15/09/2023 à 10:31, DrPi a écrit : > Bonjour, > > J'ai été biberonné au C. Pour gérer les erreurs, pas le choix : retour > de code d'erreur à chaque fonction. > > En Ada, il y a les exceptions. > Y a t-il des règles Ada à respecter/recommandées pour la gestion des > erreurs ? Les exceptions sont le meilleur moyen de traiter les situations... exceptionnelles, i.e. celles qui obligent à sortir du traitement normal. En particulier: - On ne peut pas ignorer une exception. Si elle n'est pas traitée, elle arrête le programme. Si un code d'erreur n'est pas testé, on continue avec des données fausses (et C facilite ça en autorisant d'ignorer le résultat d'une fonction). Grand principe: "il n'y a qu'une chose pire qu'un programme qui se plante, c'est un programme qui donne des résultats faux mais vraisemblables" - Il y a souvent plusieurs niveaux d'appel entre celui qui diagnostique un problème et celui capable de le traiter. Les exceptions propagent toutes seules. Avec les codes d'erreur, chaque niveau recevant une erreur du dessus doit recréer un code d'erreur pour le niveau du dessous > Par exemple, si j'ai bien compris, pour pouvoir prouver un programme, > les exceptions sont interdites. > Dans les codes sécuritaires, les exceptions posent problème parce qu'elles causent des débranchements cachés, d'où problème pour calculer le nombre cyclomatique ou prouver une couverture totale. De plus, on y a les moyens (humains, techniques et financiers) pour prouver que tous les codes de retour sont effectivement testés. Mais pour ceux qui n'ont ni les contraintes, ni les moyens financiers du SIL4, je pense que les exceptions sont préférables (et à mon avis sous-utilisées). Exemple d'utilisation hors cas d'erreur: une procédure de recherche récursive dans une structure. Quand on a trouvé, on lève une exception que l'on récupère au premier niveau. Cela évite une tonne de tests du type "si le niveau du dessus a la réponse, alors on retourne au niveau du dessous". -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX https://www.adalog.fr https://www.adacontrol.fr