Re: Assertion pour les exceptions

Le 12 janv. 2022 à 07:39, Jean-Pierre Rosen via Ada-france a écrit :

> Le 11/01/2022 à 21:44, Thomas De Contes via Ada-france a écrit :
>> Dit-on plutôt "soulever", "lever", ou "déclencher" ?
>> (Avant je disais "renvoyer", mais apparemment c'est pas bon.)
> Officiellement, "lever" en français.

Ah bon, j'aimais bien "déclencher".
Mais tant pis, puisqu'il y a un mot officiel autant s'en servir.


>> Mais je crois me souvenir d'avoir entendu parler d'un type d'assertions (ou quelque chose de similaire) qui concernerait les exceptions.
>> Ça permettrais d'indiquer dans la spec si un sous-programme peut déclencher telle ou telle exception, ou s'il ne devrais en déclencher aucune.
>> Et ça aurais un effet du genre : si ça déclenche une exception qui n'a pas été prévue dans la spec, ça la remplace par Assertion_Error.
>> 
>> Est-ce que j'ai rêvé ou pas ?
>> (C'est bête, c'est quelque chose qui m'a complètement échappé dernièrement alors que j'avais l'occasion de m'en servir ... Tant pis, je me renseigne pour la prochaine fois :-) )
>> 
> Il est possible de mettre dans une pré-condition une "expression raise", c'est à dire que "raise" peut être considéré comme une expression compatible avec n'importe quel type.

C'est marrant, une "expression raise" peut vraiment être mise dans n'importe quelle expression n'importe où, pas uniquement à des endroits prévus comme l'aspect Predicate_Failure.

> Cela permet d'exprimer quelle exception est levée si la pré-condition n'est pas respectée
> (par exemple, 13.13.1(29/5).

Pas trouvé. Chez moi 13.13.1 correspond à "The Package Streams" et ne contient que 11 lignes.

J'ai failli dire que c'est une question que je n'aurai plus besoin de poser puisqu'elle "est répondue", sauf que je ne vois toujours rien dans les pré-conditions qui concerne les "expressions raise" :

Est-ce que tu proposes de l'encadrer avec un truc du genre "(if not <pré-condition> then <expression raise>)" ?

On aurait pu laisser les gens utiliser la même astuce pour les prédicats de sous-type, du coup, non ?


> 
> Il n'y a pas de contrat sur les exceptions, car ça pose un gros problème avec l'héritage. Si on a une pile dont le contrat dit que Push peut lever l'exception Pile_Pleine et rien d'autre, alors on interdit une implémentation sur disque qui serait susceptible de lever des erreurs d'entrée-sortie. Bien sûr, Java a fait l'erreur, et ils ont été obligés de rajouter des "unchecked exceptions" qui ne sont pas héritées.

Je suis tenté de dire que dans ce cas le dispositif a juste à remplacer l'exception imprévue par Assertion_Error, puisque le développeur de la spécification n'a pas pensé à tout.
(D'ailleurs il me semble que pour faire les choses proprement on est tenu de tout prévoir dans la spécification, même si pour l'instant ça reste uniquement en commentaires donc le compilateur ne s'en mêle pas.)

Mais je devine que les exceptions sont beaucoup plus subtiles qu'elles n'en ont l'air au 1er coup d'oeil (comme tu me l'avais déjà dit à propos de l'affectation), donc je ne vais pas m'engouffrer là-dedans pour l'instant :-)


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france