URL: https://linuxfr.org/users/montaigne/journaux/contrats-et-exceptions Title: Contrats et exceptions Authors: Ontologia Date: 2009年03月12日T14:01:06+01:00 Tags: Score: 4 Un très intéressant article dans 01 sur l'introduction de la programmation par contrat dans les langages .NET. En passant, Sun va devoir faire vite évoluer Java, car celui-ci commence à prendre du retard niveau fonctionnalités sur C#/.NET : langage LINQ, closures ([certains préfèrerai un type Block à la SmallTalk/Ruby/Lisaac/etc...](http://gleichmann.wordpress.com/2008/02/10/blocks-an-alternative-for-closures/)) C'est l'opinion de Betrand Meyer, créateur d'Eiffel qui est ici intéressant : celui-ci regrette le maintien du système d'exceptions, le qualifiant de mécanisme "brutal". J'ai déjà parlé [ici](https://linuxfr.org/~Montaigne/27670.html) de notre discussion sur ce problème, lors de notre réunion annuelle du projet Isaac. Nicolas [avait lancé ici même le débat il y a un peu plus d'un an](https://linuxfr.org/~nicOnicO/25834.html) A première analyse, [Mildred avait très bien analysé les avantages/inconvénient des deux systèmes (contrats et exceptions)](http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Gestion%20des%20erreurs/gestion_des_erreurs-1.pdf). Si on synthétise un peu, on arrive à la conclusion que : * Les contrats sont parfait pour vérifier la validité des données transmises aux méthodes, ie. les erreurs statiques. Elle permettent en outre une bonne documentation (comme le souligne à raison B. Meyer), et couvre une partie de la problématique de test de manière déclarative * Les exceptions sont un très bon mécanisme pour gérer les erreurs dynamique (impossible d'ouvrir un fichier, donnée extérieur attendue non disponible, etc...) Bref, toutes les erreurs venant du monde extérieur à propos desquels le programme ne peut pas grand chose On oublie souvent la notion de contrôle d'invariant dans les contrats, qui ne sont pas que des asserts pre/post. Ils sont important pour la vérification du code, et dans sa [thèse](http://www.lri.fr/~filliatr/ftp/publis/these.ps.gz), J-C Filliâtre insiste sur le fait que ceux-ci sont essentiel pour la preuve de code. C'est d'ailleurs pour cela que cet nouvelle feature, va permettre à krosoft de proposer de la vérification statique à la compilation, par model checking, ou peut être une espèce d'analyse de flot sur le code de la machine virtuelle (mais j'y crois moins). Autre problème, évoqué à la fin de l'article : la détection des appels sur Null. Il y est fait référence du mécanisme de void safety d'Eiffel. Je ne sais pas comment ça marche, et ce que cela permet vraiment de détecter, ni si cela implique de blinder le code contrats (google ne me donne pas grand chose). Je vais encore parler de Lisaac (désolé...) puisqu'un mécanisme de détection d'appel sur Null très efficace y est implémenté. On peut assimiler un Null à un type. Donc si l'on est capable de tracer tous les typages possibles dans tous les chemins d'exécution du code, on peut retrouver la très grande majorité des appels sur Null, le restant étant les cas où les informations sont insuffisantes pour les détecter (les erreurs dynamiques justement). On a deux technique de prédiction de type : * Le lambda calcul de type, implémenté dans Objective Caml * L'analyse de flot implémenté dans Lisaac et (il me semble) Pypython Ce genre de détection évite pas mal de tests à effectuer. Mais revenons sur les contrats. Dans l'hypothèse de Meyer, il n'y (quasiment) pas d'exceptions, et toutes les erreurs sont gérées par contrat. Le problème du contrat (tapez moi si je me trompe), c'est qu'il pète sur place, il ne remonte pas. Pas terrible pour gérer l'erreur, la faire remonter. De même les exception en java (en C#, je ne sais pas, mais je suppose que c'est similaire) sont à mort subite, [pas possible comme en smalltalk/Clisp de reprendre le traitement](http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_d%27exceptions#Smalltalk) Donc si on blinde la lib de contrats, on aura une belle erreur, soit un plantage, soit une log expliquant que le réseau est indisponible, le disque est plein etc... Ca plante sur place, génial. Si on a un mécanisme de rattrapage, voire de reéxecution, là ça change beaucoup de choses, car on revient en fait à un système hybride contrat+exceptions : l'erreur remonte et peu être gérée à haut niveau. Et là, dans ce cas, un invariant devient une gestion d'exception particulière. Conclusion, il faudrait peut être faire une synthèse des deux...

AltStyle によって変換されたページ (->オリジナル) /