Journal
Blog Stéphane Bortzmeyer: Le principe de robustesse, une bonne ou une mauvaise idée ?
Le principe de Postel est très connu dans le monde des protocoles réseaux : "Soyez rigoureux dans ce que produisez, soyez compréhensif avec ce qui vient des autres".
L'objectif de ce principe consiste à maximiser le respect des standards, tout en introduisant une certaine robustesse envers les erreurs mineures et prévisibles qui pourraient exister dans les différentes implémentations.
Malheureusement, ce principe est mal compris, ou plutôt poussé à son extrême : des mécanismes complexes sont mis en œuvre pour résister à des erreurs hypothétiques, ce qui amène les développeurs à se montrer moins rigoureux et à faire émerger ces erreurs. Et une fois que ces erreurs deviennent une habitude, toute nouvelle implémentation se doit de gérer ces erreurs là.
En ce qui me concerne, j'applique le principe de Postel uniquement pour les erreurs évidentes (espaces en trop, par exemple) ou pour les erreurs faciles à détecter/corriger (valeurs oubliées). Hors de question de mettre en place des heuristiques complexes telles que celles implémentées par les navigateurs pour afficher du contenu à tout prix.
Avec le temps, je me rends compte aussi que le principe de Postel tend à être incompatible avec le principe "fail fast", qui consiste à dire qu'une erreur devrait survenir le plus tôt possible (et donc que, justement, un programme ne devrait pas chercher à corriger ou à ignorer les erreurs, mais plutôt échouer rapidement et de manière visible. En effet, l'existence d'une erreur est justement le signe que quelque chose ne va pas, et qu'il y a probablement des soucis en amont. Faire remonter ces erreurs permet de mettre en évidence ces soucis et de les corriger une bonne fois pour toute.
L'objectif de ce principe consiste à maximiser le respect des standards, tout en introduisant une certaine robustesse envers les erreurs mineures et prévisibles qui pourraient exister dans les différentes implémentations.
Malheureusement, ce principe est mal compris, ou plutôt poussé à son extrême : des mécanismes complexes sont mis en œuvre pour résister à des erreurs hypothétiques, ce qui amène les développeurs à se montrer moins rigoureux et à faire émerger ces erreurs. Et une fois que ces erreurs deviennent une habitude, toute nouvelle implémentation se doit de gérer ces erreurs là.
En ce qui me concerne, j'applique le principe de Postel uniquement pour les erreurs évidentes (espaces en trop, par exemple) ou pour les erreurs faciles à détecter/corriger (valeurs oubliées). Hors de question de mettre en place des heuristiques complexes telles que celles implémentées par les navigateurs pour afficher du contenu à tout prix.
Avec le temps, je me rends compte aussi que le principe de Postel tend à être incompatible avec le principe "fail fast", qui consiste à dire qu'une erreur devrait survenir le plus tôt possible (et donc que, justement, un programme ne devrait pas chercher à corriger ou à ignorer les erreurs, mais plutôt échouer rapidement et de manière visible. En effet, l'existence d'une erreur est justement le signe que quelque chose ne va pas, et qu'il y a probablement des soucis en amont. Faire remonter ces erreurs permet de mettre en évidence ces soucis et de les corriger une bonne fois pour toute.
Ce journal est basé sur Ginger, un gestionnaire de lien minimaliste développé dans le cadre d'un stage de perfectionnement. Pour plus d'informations, consulter le wiki consacré à mes projets personnels.