C-SHARP - 7.4 Programmation défensive

La programmation défensive part d'un principe simple : ne jamais faire confiance aveuglément aux données qui entrent dans une méthode. Que ces données viennent d'un utilisateur, d'un appel API, d'un fichier ou d'une autre partie du code, elles peuvent être nulles, vides, hors plage, malformées. Une méthode bien écrite vérifie ses hypothèses dès le départ et réagit clairement quand elles ne sont pas respectées.

Le premier réflexe est la validation explicite des paramètres en début de méthode. Une vérification if (input == null) throw new ArgumentNullException(nameof(input)); documente l'attente et signale immédiatement un usage incorrect, plutôt que de laisser le code planter trois niveaux plus loin avec un message obscur. Pour les chaînes, on testera typiquement string.IsNullOrWhiteSpace ; pour les collections, on vérifiera la présence d'éléments ; pour les nombres, on contrôlera les bornes attendues.

La gestion des exceptions est l'autre pilier. Plutôt que de capturer un catch (Exception) global qui masque les vrais problèmes, on attrape des exceptions spécifiques (FormatException, FileNotFoundException, InvalidOperationException) avec une réaction adaptée à chacune. Lorsque la situation est irrécupérable au niveau actuel, on laisse remonter l'exception pour qu'elle soit gérée plus haut, là où le contexte permet une décision pertinente.

Cette approche n'est pas une obsession sécuritaire : c'est un investissement de quelques lignes qui évite des heures de débogage. Le code défensif est plus long mais beaucoup plus prévisible. Combiné avec les outils de débogage vus précédemment et la suppression des effets secondaires, il forme le triptyque d'un code C# professionnel.