apprendre

Déboguer une application Symfony : de l'erreur au bug silencieux

Déboguer une application Symfony, c'est remonter d'un symptôme au code fautif avec la page d'erreur, sa pile d'appels et les commandes de la console.

// Aucune erreur : le message s'affiche, la page se redirige… et la base reste vide.
if ($form->isSubmitted() && $form->isValid()) {
    $entityManager->persist($plat);
    // Il manque : $entityManager->flush();
    $this->addFlash('success', sprintf('« %s » est à la carte !', $plat->getNom()));

    return $this->redirectToRoute('app_menu');
}

Une erreur bruyante se lit sur la page d'exception : le titre donne le type et le message, la pile d'appels mène au premier fichier qui n'est pas dans vendor/. Les bugs silencieux demandent d'autres témoins. doctrine:schema:validate repère un mapping incohérent, dbal:run-sql montre ce qui est vraiment en base, debug:router, debug:container, debug:event-dispatcher ou debug:messenger disent comment Symfony a assemblé l'application, et le code de sortie d'une commande dit ce qu'un script en comprend. Le piège : croire qu'une page qui s'affiche est une page juste. Un persist() sans flush(), comme ci-dessus, ne lève rien ; seule la base montre que rien n'a été enregistré.

Les exercices sont des combats de boss : Pipin a « amélioré » la taverne, et il faut trouver trois ou quatre bugs à partir des seuls symptômes. On y croise une route renommée, une relation mal nommée, un jeton CSRF qui ne correspond plus, une règle access_control trop large, un message Messenger perdu, une migration dont l'annulation vide une table, un workflow mal décrit et une commande qui annonce un succès trompeur.

10 exercices font travailler cette notion, en écrivant du code dans le navigateur.

Dans les parcours

Notions voisines

FormulaireCSRFaccess_controlVoterPare-feu#[Groups]MessengerScheduler