Result en C# : le pattern d’aujourd’hui, et sa suite
Comment gérer proprement un échec métier en C# sans transformer chaque cas prévisible en exception ?
Un utilisateur introuvable, un solde insuffisant ou une référence inexistante sont des situations qui peuvent parfaitement faire partie du fonctionnement normal d’une application. Pourtant, en C#, plusieurs approches coexistent : exceptions, null, pattern Try ou encore tuples faits maison… chacune avec ses limites.
Dans cet article, je vous propose de découvrir :
➡️ pourquoi ces approches ne répondent pas toujours correctement au besoin ;
➡️ comment le pattern Result<T> permet de représenter explicitement un succès ou un échec ;
➡️ comment construire son propre Result<T> et quelles sont ses limites ;
➡️ ce que des librairies comme FluentResults et ErrorOr apportent en plus ;
➡️ et surtout, comment C# 15 et les unions de types pourraient enfin fournir une solution native à ce besoin.
Une plongée dans la gestion des erreurs en C#, mais aussi dans l’évolution du langage et la manière dont certaines pratiques de développeurs finissent par devenir des fonctionnalités natives.
Bonne lecture !