La parole est aux speakers : Baptiste Langlade

Publié le

Jusqu’au Forum PHP 2021, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Les Exception : le trou dans la raquette du typage

Ces dernières années les outils d'analyse statique du code (comme Psalm ou PHPStan) se sont imposés dans nos projets. Ils permettent de nous montrer des erreurs en l'espace de quelques secondes sans avoir à exécuter notre code.

Les exceptions font également partie intégrante de nos projets car elles offrent une manière simple pour sortir du chemin d'exécution nominal. Cependant ce mécanisme opère en dehors du système de typage (puisqu'elles n'apparaissent pas dans la signature des fonctions) ce qui empêche les outils d'analyse statique de vérifier que chaque Exception est gérée correctement. Ce manque d'outillage nous impose de faire cette vérification via des tests fonctionnels (donc plus lents à détecter les problèmes).

On verra comment le pattern Monad (via Either et Maybe) venant de la programmation fonctionnelle nous permet de gérer nos exceptions d'une manière compréhensible par les outils d'analyse statique. Le but étant d'accélerer et d'augmenter la fiabilité de la gestion des erreurs en supprimant le besoin d'écrire des tests nous même.

Grace Hopper / Orly
22/10/2021
15:10-15:50

Tu vas nous présenter ta conférence « Les Exception : le trou dans la raquette du typage ». Est-ce qu’il y a eu un élément déclencheur qui a amené cette question comme par exemple l’écriture de test, du refactoring de code ou autre ?

Un cas que je me retrouve souvent à faire par manque « d’outils » pour mieux faire est l’utilisation d’exceptions en tant qu’unité de contrôle. Par exemple dans le pattern delegator on essaie une stratégie, si c’est pas la bonne on lève une exception qui est catched puis on tente la stratégie suivante jusqu’à trouver une stratégie qui passe. Le problème est que c’est un détournement du principe de base qui est de défausser dans le cas où ne peut plus rien faire.

Pourrais-tu nous présenter un exemple de cas d’utilisation, où à ton avis, les Exceptions sont mal utilisées ?

C’est effectivement un sujet qui me tracasse depuis 2-3 ans suite à beaucoup d’erreurs lors de refactoring qui introduisait de nouvelles exceptions qui n’étaient pas catched dans tous les usages. Ces manquements n’apparaissent qu’au runtime, que ce soit en phase de tests ou en production, réduisant la confiance dans la stabilité du code. J’ai donc commencé à chercher des outils d’analyse de code et regarder comment les autres languages adressent ce problème. Je n’ai trouvé que des solutions qui étaient soit trop compliquées, soit incomplètes, jusqu’à ce que je m’intéresse aux monads et que je comprenne que je cherchais à résoudre le mauvais problème.

Fais-tu partie de l’équipe try/catch global ou de celle au plus près de l’exception ?

Je fais partie des deux équipes. Comme je disais au début j’utilise les try/catch au plus près en tant qu’unité de contrôle. Mais j’utilise aussi des try/catch globaux (dans le controller) pour retourner une réponse compréhensible au client. Typiquement un try/catch local va permettre d’avoir une valeur par défaut dans le catch si la valeur que j’essaie d’obtenir dans le try ne fonctionne pas. Dans un try/catch de controller je l’utilise pour catch des exceptions comme une entité que j’essaie de modifier qui n’existe pas (peu importe où dans la call stack elle est levée) ce qui permet de retourner une réponse HTTP 404.

Une conférence présentée par

Baptiste LANGLADE
Baptiste LANGLADE
Baptiste Langlade est un développeur PHP (certifié symfony2) passionné par indexer internet, Neo4j et le fonctionnement du cerveau.

Autres interviews