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