En lisant la documentation d’erreurs de Newton's VaultKit, je m’attendais à y trouver la liste habituelle des exceptions que les développeurs devraient intercepter et ignorer. Au lieu de ça, j’ai découvert quelque chose de bien plus intéressant.
La documentation insiste sans le dire directement : toutes les défaillances ne méritent pas la même réponse.
Ça paraît évident, mais beaucoup de systèmes ne le reflètent pas.
Quand quelque chose tourne mal, notre première instinct est généralement de retenter. Peut-être que le réseau était lent. Peut-être que le service était temporairement indisponible. Peut-être que la prochaine tentative réussira. Mais Newton trace une ligne très claire entre l’échec temporaire et l’échec déterministe.
Je pense que c’est l’une des idées les plus précieuses de cette section.
Si une passerelle expire ou si une attestation met plus de temps que prévu, retenter a du sens car la requête sous-jacente n’est pas nécessairement devenue invalide. Mais si la politique, elle-même, refuse l’action, retenter exactement la même requête ne sert à rien. La décision a déjà été prise en fonction des règles en vigueur.
Cette distinction m’a immédiatement frappé.
Elle fait passer l’état d’esprit du développeur de « Comment faire réussir cette transaction ? » à « Pourquoi cette transaction a-t-elle échoué ? »
Ce sont des questions complètement différentes.
Un autre détail que j’ai apprécié, c’est à quel point Newton met l’accent sur le diagnostic plutôt que sur de simples messages d’erreur génériques.
Le guide souligne même qu’un résumé au niveau supérieur comme « Quorum non atteint » peut masquer une explication beaucoup plus utile, côté opérateur. Un paramètre de stratégie manquant, un schéma mal formé ou un manifeste invalide peuvent produire des symptômes en surface similaires, mais ils exigent des solutions totalement différentes.
J’aime ça, parce que le débogage devient une enquête plutôt qu’un jeu de devinettes.
Le protocole sépare aussi les erreurs de configuration des échecs d’exécution.
Une chaîne non prise en charge, une stratégie incompatible, une configuration invalide ou une intention incorrecte ne sont pas traitées comme quelque chose que le réseau pourrait corriger magiquement plus tard. Ces erreurs forcent les développeurs à corriger la configuration sous-jacente avant d’essayer à nouveau.
Pour moi, c’est plus sain que d’encourager des retentatives sans fin.
Une autre chose que j’ai remarquée, c’est la cohérence du modèle d’erreur.
Chaque erreur hérite du même type de base et transporte un code d’erreur stable, en plus de la cause d’origine. Cela peut sembler un petit détail d’implémentation, mais cela crée un pont entre les opérations et l’ingénierie. Les systèmes de supervision peuvent réagir à des codes stables, tandis que les développeurs ont toujours accès au contexte détaillé nécessaire pour comprendre ce qui s’est réellement passé.
Peut-être que la leçon la plus importante pour moi n’était aucune classe d’erreur en particulier.
C’était la philosophie qui les guidait.
VaultKit n’a pas l’air de vouloir faire disparaître chaque échec. Au lieu de ça, il cherche à rendre chaque échec compréhensible.
Certaines défaillances sont temporaires.
Certaines sont intentionnelles.
Certaines sont des avertissements indiquant que la politique fait exactement ce pour quoi elle a été conçue.
Reconnaître la différence est probablement plus utile que de tout retenter automatiquement.
Après avoir lu cette section, j’ai eu l’impression que Newton traite la gestion des erreurs comme faisant partie du modèle de confiance du protocole, et pas seulement comme une commodité pour les développeurs.
Quand l’infrastructure explique pourquoi quelque chose s’est arrêté au lieu de se contenter de signaler qu’il s’est arrêté, la construction de systèmes fiables devient beaucoup plus simple.
Pour moi, c’est l’une des forces de @NewtonProtocol les plus sous-estimées.