Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
To except or not to except ?
2 views
Skip to first unread message
DrPi
Sep 15, 2023, 4:31:49 AM9/15/23
to
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 ?
Par exemple, si j'ai bien compris, pour pouvoir prouver un programme,
les exceptions sont interdites.
Nicolas
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 ?
Par exemple, si j'ai bien compris, pour pouvoir prouver un programme,
les exceptions sont interdites.
Nicolas
J-P. Rosen
Sep 15, 2023, 4:59:26 AM9/15/23
to
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...
> 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 ?
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.
>
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
DrPi
Sep 16, 2023, 5:32:24 AM9/16/23
to
Le 15/09/2023 à 10:59, J-P. Rosen a écrit :
> > 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
Pour le fonctionnement des exceptions, c'est OK. J'ai compris le
> > 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
principe. A moins qu'il y ait des subtilités spécifiques à Ada.
> > 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).
maison. Même si je ne désespère pas utiliser Ada au boulot (pas de SIL4
non plus).
> 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".
Merci Jean-Pierre.
Stéphane Rivière
Oct 7, 2023, 4:06:30 AM10/7/23
to
Une exception est un goto déguisé mais tous les goto ne sont pas à
jeter. Pas plus que les exit dans une boucle sont bien pratiques.
Je tente de suivre exactement ce que préconise Jean-Pierre. Parfois
c'est un vrai gain de lisibilité, il faut juste choisir quand les
utiliser avec du bon sens.
Un cas où je les utilise est de récupérer toutes les erreurs (pour les
enregistrer dans un log à des fins de déverminage ultérieur) pour
ensuite repartir dans le programme (cas d'un prog qui doit tourner
365/24 et qui gère, par exemple, des sessions web - au sens où chaque
nouvelle session web est une 'nouvelle vie' du code, si je puis
m'exprimer ainsi).
Je perds pas les erreurs et, en même temps, le prog est toujours dispo.
On peut aussi les utiliser quand on a des choses très dynamiques comme
des requêtes SQL, possiblement enregistrées par un utilisateur, et qui
peuvent être syntaxiquement incorrectes. Avant de les enregistrer, on
les lance et si exception, récupération et on balance (avec des fleurs)
le message d'exception à l'utilisateur afin qu'il révise sa requête.
--
Stéphane Rivière
Ile d'Oléron - France
jeter. Pas plus que les exit dans une boucle sont bien pratiques.
Je tente de suivre exactement ce que préconise Jean-Pierre. Parfois
c'est un vrai gain de lisibilité, il faut juste choisir quand les
utiliser avec du bon sens.
Un cas où je les utilise est de récupérer toutes les erreurs (pour les
enregistrer dans un log à des fins de déverminage ultérieur) pour
ensuite repartir dans le programme (cas d'un prog qui doit tourner
365/24 et qui gère, par exemple, des sessions web - au sens où chaque
nouvelle session web est une 'nouvelle vie' du code, si je puis
m'exprimer ainsi).
Je perds pas les erreurs et, en même temps, le prog est toujours dispo.
On peut aussi les utiliser quand on a des choses très dynamiques comme
des requêtes SQL, possiblement enregistrées par un utilisateur, et qui
peuvent être syntaxiquement incorrectes. Avant de les enregistrer, on
les lance et si exception, récupération et on balance (avec des fleurs)
le message d'exception à l'utilisateur afin qu'il révise sa requête.
--
Stéphane Rivière
Ile d'Oléron - France
J-P. Rosen
Oct 7, 2023, 1:07:42 PM10/7/23
to
Le 07/10/2023 à 10:06, Stéphane Rivière a écrit :
> Une exception est un goto déguisé
Mais toutes les structures de contrôle (if, case, loop) sont des goto
> Une exception est un goto déguisé
déguisés... On peut même dire que le but des structures, c'est de
déguiser des goto.
Avec un avantage en plus: la structure dit /pourquoi/ on se débranche.
Le goto est muet sur ce point.
(sorry, couldn't resist :-) )
DrPi
Oct 7, 2023, 2:07:33 PM10/7/23
to
Le 07/10/2023 à 10:06, Stéphane Rivière a écrit :
Le plus dur est de déterminer quand utiliser une exception. Parfois
c'est évident. D'autres fois, ça l'est beaucoup moins.
Merci pour ton retour.
Stéphane Rivière
Oct 8, 2023, 4:29:07 AM10/8/23
to
> Mais toutes les structures de contrôle (if, case, loop) sont des goto
> déguisés... On peut même dire que le but des structures, c'est de
> déguiser des goto.
Oui !
> déguisés... On peut même dire que le but des structures, c'est de
> déguiser des goto.
> Avec un avantage en plus: la structure dit /pourquoi/ on se débranche.
> Le goto est muet sur ce point.
> (sorry, couldn't resist :-) )
semaine)... tu as bien eu raison de ne pas résister :)
0 new messages