Les exceptions

Tu as déjà croisé une exception sans la comprendre

À la leçon 2, dans le setter de Produit, on a écrit ceci sans s'arrêter dessus :

public function setPrix(float $prix): void {
    if ($prix < 0) {
        throw new InvalidArgumentException("Prix négatif interdit");
    }
    $this->prix = $prix;
}

Ce throw new InvalidArgumentException, il est temps de comprendre ce qu'il fait vraiment. Il répond à une question qui revient sans cesse : que fait une méthode quand elle ne PEUT PAS faire son travail ? Un prix négatif, un solde trop bas, un fichier absent.

La mauvaise réponse, c'est le code d'erreur. retirer() renvoie false quand ça échoue. Une autre méthode renvoie null. Une troisième renvoie -1. L'appelant doit deviner la convention de chacune, et surtout penser à tester le retour à chaque appel. Un oubli, et le programme continue avec une valeur fausse. C'est le chaos des codes d'erreur.

throw : arrêter net avec un objet qui raconte tout

Lever une exception, c'est dire « je ne peux pas continuer » et arrêter la méthode immédiatement. À la ligne du throw, l'exécution de la méthode s'interrompt : les lignes suivantes ne tournent pas. PHP remonte alors la pile d'appels à la recherche de quelqu'un pour gérer le problème.

Et ce n'est pas un simple message : une exception est un objet. Comme tout objet (leçon 1), elle porte des données et des méthodes. Elle sait raconter ce qui s'est passé :

• $e->getMessage() : le message lisible que tu as écrit.
• $e->getFile() et $e->getLine() : le fichier et la ligne exacts du throw.
• $e->getCode() : un code numérique optionnel.
• $e->getTrace() : toute la pile d'appels qui a mené là.

function diviser(int $a, int $b): float {
    if ($b === 0) {
        throw new InvalidArgumentException("Division par zéro interdite");
    }
    return $a / $b;   // sauté si b vaut 0
}

Si personne ne l'attrape, l'exception devient une erreur fatale et le script s'arrête. Ce n'est pas un défaut : mieux vaut un arrêt net et bruyant qu'un résultat faux qui se propage. La suite montre comment l'attraper proprement.

try / catch : attraper le problème

Pour gérer une exception au lieu de planter, on entoure le code risqué d'un bloc try, suivi d'un catch qui récupère l'objet exception. Le flux d'exécution est précis :

• Le code du try s'exécute normalement, ligne après ligne.
• Si un throw survient (ici ou dans une méthode appelée), PHP saute tout le reste du try et bondit dans le catch.
• Le catch reçoit l'objet exception, le traite, puis l'exécution reprend normalement après le bloc.
• Si aucun throw ne survient, le catch est tout simplement ignoré.

try {
    $r = diviser(10, 0);
    echo "Résultat : $r";     // sauté : le throw a eu lieu avant
} catch (InvalidArgumentException $e) {
    echo "Souci : " . $e->getMessage();   // on récupère le contrôle ici
}
echo "\nLe programme continue.";   // exécuté dans tous les cas

Et finally ? Un bloc optionnel après le catch, exécuté quoi qu'il arrive : succès, exception attrapée, ou même exception relancée. C'est l'endroit du nettoyage qu'on ne veut jamais oublier : fermer un fichier, libérer une connexion à la base.

Lever et attraper : exécute

Un compte qui refuse un retrait à découvert, non plus avec un false muet (leçon 2), mais avec une exception qui explique le problème. Note bien : le programme continue après le catch.

<?php
class Compte {
    private float $solde = 0;

    public function deposer(float $m): void { $this->solde += $m; }

    public function retirer(float $m): void {
        if ($m > $this->solde) {
            throw new RuntimeException(
                "Solde insuffisant : il manque " . ($m - $this->solde) . " €"
            );
        }
        $this->solde -= $m;
    }
    public function getSolde(): float { return $this->solde; }
}

$c = new Compte();
$c->deposer(50);

try {
    $c->retirer(200);                 // lève l'exception
    echo "Retrait effectué\n";       // sauté
} catch (RuntimeException $e) {
    echo "Erreur : " . $e->getMessage() . "\n";
} finally {
    echo "Solde : " . $c->getSolde() . " €\n";   // toujours exécuté
}

echo "Le programme continue normalement.\n";
?>

La hiérarchie : du spécifique au général

Toutes les exceptions descendent d'une seule classe de base : Exception. PHP fournit ensuite une famille toute prête, les exceptions SPL, qui en héritent :

• InvalidArgumentException : un argument reçu est invalide (prix négatif, format faux).
• RuntimeException : un problème survenu à l'exécution (solde trop bas, ressource indisponible).
• LogicException : une erreur de logique du programme, qu'on aurait dû éviter en codant.

Et c'est ici que l'héritage de la leçon 3 paie comptant. Un catch attrape une classe et toutes ses classes filles : c'est du polymorphisme. Comme InvalidArgumentException hérite (indirectement) d'Exception, un catch (Exception $e) attrape aussi les InvalidArgumentException.

Conséquence directe : on attrape du plus spécifique au plus général. Un catch trop large placé en premier raflerait tout, et les catch plus précis en dessous ne serviraient jamais.

<?php
function valider(int $age): void {
    if ($age < 0)   throw new InvalidArgumentException("Âge négatif");
    if ($age > 150) throw new RuntimeException("Âge irréaliste");
}

foreach ([-5, 200, 30] as $age) {
    try {
        valider($age);
        echo "$age : valide\n";
    } catch (InvalidArgumentException $e) {     // le plus spécifique d'abord
        echo "$age : argument invalide (" . $e->getMessage() . ")\n";
    } catch (Exception $e) {                    // le filet de sécurité, en dernier
        echo "$age : autre erreur (" . $e->getMessage() . ")\n";
    }
}
?>

Tes propres exceptions : du métier dans le nom

Réutiliser une exception SPL suffit souvent. Mais parfois, le nom de l'erreur doit parler le langage de ton domaine. CommandeIntrouvableException raconte le problème métier bien mieux qu'un RuntimeException générique. Et créer la sienne est trivial : il suffit d'étendre Exception (encore l'héritage de la leçon 3).

<?php
// Une exception métier : son nom dit déjà tout
class CommandeIntrouvableException extends Exception {}

class Catalogue {
    private array $commandes = ["CMD-1" => 49.90, "CMD-2" => 12.00];

    public function montant(string $ref): float {
        if (!isset($this->commandes[$ref])) {
            throw new CommandeIntrouvableException("Commande $ref introuvable");
        }
        return $this->commandes[$ref];
    }
}

$cat = new Catalogue();
foreach (["CMD-1", "CMD-9"] as $ref) {
    try {
        echo "$ref : " . $cat->montant($ref) . " €\n";
    } catch (CommandeIntrouvableException $e) {   // on cible précisément ce cas
        echo "Souci métier : " . $e->getMessage() . "\n";
    }
}
?>

La règle de décision : réutilise une SPL tant qu'elle décrit bien le problème (argument invalide, état d'exécution). Crée la tienne dès que tu veux l'attraper de façon ciblée, ou quand son nom apporte une information métier que l'appelant doit pouvoir distinguer.