# Gestion des exceptions

> Mécanisme du langage permettant d'interrompre proprement l'exécution en cas d'erreur, de la « lancer » puis de la « rattraper » pour la traiter.

- Auteur : Clément Hadrot
- Publié le : 2026-09-25
- Mis à jour le : 2026-09-25
- URL : https://wpmoderne.dev.wordpress-developpement.fr/lexique/gestion-exceptions/

Plutôt que de laisser un script s'arrêter brutalement quand une opération échoue — un fichier introuvable, une valeur inattendue —, PHP permet de signaler l'incident sous forme d'objet (une exception) que le code appelant peut choisir de traiter. C'est un peu comme lever la main en cours pour signaler un problème, plutôt que de quitter la salle sans explication.

## Fonctionnement en PHP

On déclenche une exception avec `throw new Exception('message')`, et on l'intercepte avec un bloc `try { ... } catch (Exception $e) { ... }`. Un bloc `finally` optionnel s'exécute dans tous les cas, qu'une exception ait été levée ou non. PHP fournit une hiérarchie de classes (`TypeError`, `ValueError`, `InvalidArgumentException`…) toutes descendantes de l'interface `Throwable`.

## Dans WordPress

Le cœur historique de WordPress évite les exceptions et préfère la classe `WP_Error`, retournée par des fonctions comme `wp_insert_post()` en cas d'échec. Les API plus récentes (REST API, certaines classes de `WP_REST_Controller`) et la plupart des bibliothèques Composer utilisées dans les extensions, elles, s'appuient pleinement sur les exceptions.

## Exemple

```
try {
    $resultat = 10 / $diviseur;
} catch (DivisionByZeroError $e) {
    error_log('Division invalide : ' . $e->getMessage());
    $resultat = 0;
}
```

## Bon à savoir

Un bloc `catch` trop large (`catch (\Throwable $e)` partout) masque des bugs qui mériteraient de remonter. Dans une extension qui mélange du code WordPress classique et des bibliothèques externes, il est courant de convertir une exception attrapée en `WP_Error` avant de la faire remonter à l'utilisateur, pour rester cohérent avec les conventions du cœur.