Keeping it real, faire apparaitre et assurer la prise en compte des cas d'erreur

Si je vous dit que j'ai une fonction getUser qui retourne un utilisateur, vous me croyez ?

Une meilleur description de la fonction serait probablement "avec un peu de chance, la fonction getUser retourne un utilisateur". Dans le reste des cas... 🤗

Que ce soit la liste des différents erreurs possibles pour une fonction ou la probabilité d'un undefined, le "sad path" est souvent implicite dans nos programmes.

Cette difficulté à cerner le domaine d'erreurs possibles rends leur prise en compte difficile et se traduit souvent par une 500 de la mort (©) où, quoi que fasse l'utilisateur, son action se termine invariablement par une erreur 500, sans aucune indication du problème rencontré ou des solutions possibles.

Dans ce talk nous verrons comment modéliser l'incertitude dans nos programmes et ainsi faire apparaitre les "sad paths" et assurer leur prise en charge, tout en réduisant leur complexité de gestion.

Au programme:

• partial vs total fns documentation exhaustive
• Modéliser l'absence de donnée
• Modéliser la possibilité d'erreur et succès
• Court circuiter la complexité de gestion des nulls et erreurs

Notes:

• Une bonne partie de ce talk va reposer sur les types, mais un langage dynamique profitera probablement encore plus des data types qui seront présentés.
• La présentation se fera probablement via Typescript où Scala mais se transfère aisément à tout langage.