# Erreurs et exceptions en PHP > Erreurs et exceptions en PHP : Throwable, Error et Exception, try/catch/finally, gestionnaires globaux et réglages sûrs pour l'affichage des erreurs et les logs. Source : https://phpsos.de/fr/php/fehler-und-exceptions/ État : 25/10/2026 Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6 **En bref :** PHP signale les problèmes de deux façons : sous forme d'erreurs classiques, comme les avertissements et les notices, pilotées par `error_reporting`, et sous forme d'exceptions, qui peuvent être interceptées avec `try` et `catch`. Depuis PHP 7, de nombreuses erreurs internes lèvent elles aussi un objet de la classe `Error` ; avec `Exception`, elle implémente l'interface `Throwable`. En production, la règle est : consigner les erreurs, ne jamais les afficher dans le navigateur. Sur PHP 8.5, `fatal_error_backtraces=0` fait en outre partie des mesures transitoires contre PHP2Shell. ## Deux mondes : erreurs classiques et exceptions PHP date d'une époque où les erreurs étaient avant tout affichées sous forme de message : notices (`E_NOTICE`), avertissements (`E_WARNING`), fonctions obsolètes (`E_DEPRECATED`) et erreurs fatales (`E_ERROR`). Beaucoup de ces messages laissent le script continuer, souvent avec des données erronées ou vides. Les exceptions fonctionnent autrement. Elles interrompent le déroulement normal et sautent au prochain bloc `catch` approprié. Si aucun n'est trouvé, le script s'arrête. Pour les décideurs, la différence est importante : un avertissement silencieux peut conduire à l'enregistrement incomplet d'une commande sans que personne ne s'en aperçoive. Une exception rend le problème visible et traitable. Un avantage sous-estimé des messages classiques est celui des notices de type `E_DEPRECATED`. Elles annoncent qu'une fonctionnalité du langage disparaîtra dans une future version de PHP. Qui les collecte dans le log et les exploite régulièrement sait, avant une mise à niveau, quels endroits doivent être adaptés, et n'a pas besoin de longs tests en cas de faille de sécurité urgente. ## La hiérarchie Throwable Tout ce qui peut être lancé avec `throw` et attrapé avec `catch` implémente `Throwable`. En dessous, il y a deux branches : | Classe | Rôle | Exemples de sous-classes | |---|---|---| | `Exception` | erreurs prévisibles de l'application et des extensions | `ErrorException`, `PDOException`, classes personnalisées | | `Error` | erreurs internes de PHP | `TypeError`, `ValueError`, `ArgumentCountError`, `ArithmeticError`, `DivisionByZeroError`, `UnhandledMatchError` | Les classes d'erreur personnalisées dérivent de `Exception`, non de `Error`. Depuis PHP 8.0, la plupart des fonctions internes lèvent une `TypeError` ou une `ValueError` en cas de paramètres invalides, au lieu de se contenter d'émettre un avertissement. `strlen([])` en est un exemple. ## try, catch et finally en pratique ```php belasten($b->betrag(), $b->referenz()); return true; } catch (ZahlungFehlgeschlagen $e) { $log->warning('Zahlung abgelehnt', ['bestellung' => $b->id(), 'exception' => $e]); return false; } catch (TimeoutException | VerbindungsFehler) { // depuis PHP 8.0, la variable est facultative dans le catch $log->error('Zahlungsdienst nicht erreichbar', ['bestellung' => $b->id()]); return false; } finally { $dienst->verbindungSchliessen(); } } ``` Plusieurs classes peuvent être regroupées avec `|` dans un seul `catch`. Le bloc `finally` s'exécute toujours, qu'une erreur soit survenue ou non. Depuis PHP 8.0, `throw` est en outre une expression et peut par exemple figurer derrière `??` : `$id = $_GET['id'] ?? throw new InvalidArgumentException('id fehlt');`. ## Gestionnaires globaux : set_error_handler et set_exception_handler Deux fonctions interceptent ce qui passerait sinon entre les mailles. `set_exception_handler()` enregistre une fonction pour les Throwable non interceptés. Selon le manuel, le script se termine après son appel ; elle convient donc à la journalisation et à une page d'erreur neutre, pas à la poursuite du traitement. Un gestionnaire qui écrit l'erreur complète dans le log, avec l'horodatage et un identifiant aléatoire, et ne montre au visiteur qu'une page neutre portant cet identifiant, a fait ses preuves. Le support peut alors retrouver le cas dans le log, sans que des détails internes ne filtrent vers l'extérieur. `set_error_handler()` intercepte les erreurs classiques. Le manuel montre comment les convertir en `ErrorException`, afin que les avertissements soient traités comme des exceptions : ```php