Exceptions localisées avec Symfony2

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Cet article traite de la localisation des exceptions avec Symfony2. La gestion des exceptions est un sujet à ne pas prendre à la légère. Elle aide au débuggage par les développeurs dans un premier temps, puis à l’information des techniciens de maintenance et des usagers en cas de problème une fois l’application en exploitation.

 

Cet article s’applique à Symfony 2.6.

Lancer des exceptions en cas d’erreur c’est bien. Lancer des exceptions précises et localisées, c’est mieux. En PHP, la manière la plus basique de lancer une exception est la suivante :

On peut améliorer ce lancement basique de deux manières :

  1. Personnaliser ses exceptions, en fonction de l’élément qui a généré une erreur
  2. Améliorer ses messages d’erreur

Personnaliser ses exceptions

Imaginons une application de type boutique en ligne, qui va gérer un certain nombre d’objets métiers. Pour l’exemple, nous en considérerons deux :

  • Les produits
  • Les commandes

Nous allons créer une exception par type d’objet métier. Cela nous servira de premier niveau de personnalisation. Il y a plusieurs avantages à procéder de cette façon. Il sera par exemple plus simple de différencier une erreur produit d’une erreur commande, même si la commande contient des produits. Il deviendra aussi possible de catcher au besoin ces deux exceptions dans des circuits différents. Pour nous laisser la possibilité de définir des éléments communs à nos deux extensions, nous allons d’abord mettre en place une exception abstraite.

Pour le moment, elle ne fait rien de spécial. Elle étend la classe intégrée Exception de PHP. Nous allons ensuite l’étendre pour chaque type d’objet que nous allons devoir manipuler.

Sans même ajouter de fonctionnalité à ces classes, on gagne déjà en clarté. Lorsqu’une exception sera levée, on saura par son type si elle concerne un produit ou une commande, peu importe le contenu de son message.

Améliorer ses messages d’erreur

Symfony2 dispose d’un service translator, qui permet de traduire des messages. Il gère les pluriels et la personnalisation à l’aide de variables. Nous allons l’employer à la traduction et la personnalisation des messages d’erreur.

Tout se déroule dans la classe abstraite. Elle est étendue par les autres, qui hériteront de son comportement.

Le prototype (ligne 26) est le même que celui d’une Exception de base de PHP, auquel nous ajoutons un tableau de paramètres pour le service translator. Ces paramètres sont généralement des variables à insérer dans le message traduit, comme le nom de la classe concernée par l’erreur ou une représentation textuelle de la données en erreur.

Nos exceptions n’ont pas accès au conteneur de services de Symfony2. Nous allons ruser en accédant à l’objet global $kernel, qui nous donnera accès au conteneur de services (lignes 28 à 32).

Le paramètre $message devient en réalité une clé de traduction (ligne 34). Si elle n’est pas référencée dans le fichier Yaml (voir ci-dessous), elle sera simplement utilisée telle quelle, rendant notre exception transparente. Il est toutefois possible que des warnings soient rapportés. Au cas où vous ne souhaitez pas les corriger, vous pouvez demander à Symfony2 de ne pas journaliser ces avertissements.

Une fois le message traduit (ou pas), il est transmis (ligne 36 à 40) au constructeur parent, c’est à dire celui de la classe de base Exception.

Utilisation

Au lancement d’une exception, nous pourrons (ou pas) utiliser le système de clés / valeurs du service translator pour appeler des codes d’erreur, qui seront traduis par le service en messages détaillés et localisés.

Le lancement de l’une de nos exceptions reste assez similaire aux exceptions classiques. Si ce n’est que l’on peut si on le souhaite raccourcir énormément les appels :

On peut aussi lui passer des paramètres :

Conclusion

Gardez à l’esprit qu’une exception doit savoir rester sobre. Une exception qui plante et lance elle-même une exception, ça fait mauvais genre. S’il y a bien une partie du code qui doit être testée et re-testée, c’est celle-ci.

Webographie

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *