Blog / Article #125

Exceptions maison dans Symfony

Les exceptions, ces petits messages d’erreur qui vous rappellent avec une élégance toute relative, que votre code a décidé de prendre des vacances sans prévenir. Dans Symfony, comme dans beaucoup de frameworks, on a tendance à se reposer sur des exceptions génériques comme RuntimeException. Après tout, pourquoi se fatiguer à créer ses propres classes quand une bonne vieille throw new RuntimeException('Oops') fait très bien l’affaire ? peut etre parce que c’est paresseux, peu maintenable, et que ça vous prive d’un outil puissant pour structurer vos erreurs.

RuntimeException, ca marche mais ca suffit pas vraiment

Utiliser RuntimeException pour tout et n’importe quoi, c’est un peu comme utiliser un marteau pour enfoncer une vis, cuire un steak et réparer votre vélo. Techniquement, ça marche. Mais est-ce que c’est optimal ? Non. Est-ce que c’est propre ? Pas vraiment. Est-ce que ça vous permet de savoir d’où vient le problème en un coup d’œil ? Absolument pas.

Prenons un exemple. Vous avez une API qui gère des commandes. Une commande ne peut pas être passée si le stock est insuffisant. Vous pourriez lancer une RuntimeException avec un message du type : 'Stock insuffisant pour le produit 123'. Super, mais maintenant, comment faites-vous pour attraper spécifiquement cette erreur dans votre code ? Vous allez devoir parser le message d’erreur comme un sauvage, ou pire, attraper toutes les RuntimeException et espérer que celle-ci soit la seule à se produire dans ce contexte. Bonne chance pour déboguer ça quand votre application aura grandi.

Et c’est là que les classes d’exception personnalisées entrent en jeu. Avec une InsufficientStockException, vous pouvez attraper uniquement cette erreur, la logger proprement, et même déclencher des actions spécifiques (comme notifier un admin ou proposer un produit de substitution). Bref, vous passez d’un bordel indéchiffrable à une architecture propre et maintenable.

Créer ses propres exceptions : plus simple que de commander un café

Créer une classe d’exception personnalisée dans Symfony, c’est aussi compliqué que de déclarer une classe PHP basique. En fait, c’est exactement ça : une classe PHP basique. Voici un exemple minimaliste :

namespace App\Exception;

use Exception;

class InsufficientStockException extends Exception
{
    public function __construct(string $productId, int $availableStock, int $requestedQuantity, int $code = 0, Exception $previous = null)
    {
        $message = sprintf(
            'Stock insuffisant pour le produit %s (disponible : %d, demandé : %d)',
            $productId,
            $availableStock,
            $requestedQuantity
        );
        parent::__construct($message, $code, $previous);
    }
}

Et voilà. Vous avez maintenant une exception qui :

• est explicite : son nom seul indique de quoi il s’agit ;
• est riche en informations : elle embarque les données nécessaires pour comprendre et résoudre le problème ;
• est facile à attraper : un simple catch (InsufficientStockException $e) et vous êtes bon.

Cerise sur le gâteau, vous pouvez même ajouter des méthodes utilitaires à votre exception. Par exemple, une méthode getProductId() pour récupérer directement l’ID du produit concerné, ou une méthode getSuggestedAlternatives() pour proposer des solutions. Bref, vous transformez une simple erreur en un outil de résolution de problèmes.

Pourquoi c’est une bonne pratique et pas juste pour faire le dev balèze^^

Certains diront que créer des exceptions personnalisées, c’est du over-engineering. Après tout, si une RuntimeException fait le job, pourquoi s’embêter ? La réponse est simple : parce que le code, c’est comme un bon vin, ça se bonifie avec le temps. Et un code qui utilise des exceptions génériques, c’est comme un vin qui a tourné : ça pue, et ça donne mal à la tête.

Voici pourquoi les exceptions personnalisées sont une bonne idée :

• Clarté : quand une exception est lancée, son nom seul vous dit ce qui ne va pas. Pas besoin de lire le message ou de fouiller dans les logs pour comprendre.
• Maintenabilité : si demain vous devez modifier le comportement de votre application en cas de stock insuffisant, vous n’avez qu’à chercher InsufficientStockException et vous savez exactement où intervenir.
• Débogage : les outils comme Symfony Profiler ou les logs deviennent bien plus utiles quand ils affichent des exceptions précises plutôt qu’un générique RuntimeException.
• Extensibilité : vous pouvez ajouter des comportements spécifiques à vos exceptions (comme des méthodes utilitaires) sans toucher au reste de votre code.

Et puis, soyons honnêtes : utiliser RuntimeException pour tout, c’est un peu comme utiliser die() pour gérer les erreurs. Techniquement, ça marche. Mais est-ce que c’est professionnel ? Non. Est-ce que ça vous fera passer pour un développeur sérieux ? Pas vraiment.

Quand est-ce que RuntimeException est acceptable ?

Bon, d’accord, je vais nuancer un peu. Il y a des cas où RuntimeException est acceptable, voire recommandé. Par exemple :

• Pour des erreurs vraiment génériques, comme une configuration manquante (throw new RuntimeException('La clé API est manquante')).
• Dans des prototypes ou des scripts jetables, où la maintenabilité n’est pas une priorité.
• Quand vous n’avez vraiment pas le temps de faire mieux (mais dans ce cas, prévoyez de refactorer plus tard).

Mais dans une application Symfony sérieuse, où vous voulez du code propre, maintenable et professionnel, les exceptions personnalisées sont la voie à suivre. Alors la prochaine fois que vous serez tenté de lancer une RuntimeException, demandez-vous : est-ce que je veux que mon code ressemble à un plat de spaghettis, ou à une architecture bien huilée ?

Et si la réponse est la deuxième option, sortez votre éditeur de texte et créez cette exception personnalisée. Votre futur vous (et vos collègues) vous remercieront.