Le problème n'est pas si simple que ça et se situe en fait, non dans les bibliothèques mais dans le langage lui-même.
Dans les faits, de nombreux langage pourtant très répandus n'intègre pas de mécanisme permettant de gérer les pré-conditions qui soit à la fois efficace, simple et qui documente ces pré-conditions.
Prenons par exemple le cas du C ou du C++ (mais de ce que j'en sais, ce n'est pas très différent en Java et probablement pas en C#):
- Les assert ne remplissent pas ce rôle : inactif en mode release, sortie violente du programme, etc.
- Les static_assert de Boost (et d'autres solutions similaires) bien que très pratique ne le remplisse pas non plus : résolu lors de la compilation donc il ne peuvent pas servir à vérifier une valeur connue uniquement au run-time.
- Le test explicite dans le code avec retour du code d'erreur adéquate : la méthode peut être efficace si le code est bien écrit, toutefois elle ne remplit pas le rôle documentaire (pas de mise en évidence, noyé dans le code qui n'est pas forcément disponible) et nécessite d'écrire pas mal de code pour gérer ces cas ce qui "pollue" le code fonctionnel (même s'il est possible de mettre ses vérifications dans une couche intermédiaire) et augmente le risque d'erreur (plus de code ==> plus de risque d'erreur).
- Les différentes sur-couches maison plus ou moins bien pensées qui encapsulent les tests et fournissent des fonctionnalités de vérification ne permettent pas une expressivité des conditions toujours suffisante.
Alors effectivement une fois que la bibliothèque est développée, validée, documentée et éprouvée, on peut se dire que les méthodes existantes sont suffisantes. Mais parvenir à ce résultat nécessite un travail important qui pourrait être amplement facilité si le langage fournissait nativement ce mécanisme.
Partager