Choses à faire

24h dans une journée, et tant de choses à faire !

PHP et la gestion des erreurs

publié le 22 mars 2010 par Pierre Quillery

PHP génère des erreurs de plusieurs niveaux, et les gérer correctement est quelque chose d’essentiel, à la fois pour des questions de sécurité et de performances. Nous allons voir dans cet article quelques règles simples qui devraient vous permettre d’optimiser facilement cet aspect de votre application.

Différents niveaux d’erreurs

Tout d’abord il est important de réaliser que PHP peut lever en permanence différents niveaux d’erreurs que vous pouvez afficher ou masquer suivant la configuration de votre fichier php.ini ou via la fonction error_reporting().

Ces niveaux sont E_ERROR (une vraie erreur), E_WARNING (un avertissement), E_PARSE (erreur de syntaxe) et E_NOTICE (mauvaise pratique) ; E_ALL est un alias pour tout logger. Par défaut, tout est loggué sauf les E_NOTICE.

Bonnes pratiques

Dans votre environnement de développement, vous devriez activer l’affichage de toutes les erreurs, y compris les E_NOTICE : cela vous forcera parfois à écrire un code un peu plus long, mais ce dernier laissera idéalement moins de choses au hasard.

Par exemple, si vous essayez d’accéder à un élément d’un tableau associatif à l’aide d’une clé qui n’a pas été définie auparavant, cela déclenchera une erreur : si vous n’êtes pas sûr que la variable a bien été définie, vous devrez tester cela avec la fonction isset().

En environnement de production, a contrario, vous devriez désactiver complètement l’affichage des erreurs, la raison est double :

  • Il est préférable de ne pas montrer les messages d’erreurs à l’internaute car ils recèlent souvent des informations sur la configuration du serveur (l’emplacement des fichiers, la connexion à la base de données etc.) qui devraient rester confidentielles.
  • Maintenir l’affichage des erreurs a un coût au niveau des performances ; je n’ai pas pu trouver de chiffres précis à ce sujet, mais intuitivement cela semble cohérent.

À éviter, le « @ »

Une mauvaise pratique consiste à utiliser l’opérateur « @ » avant un appel de fonction ou en faisant référence à une variable afin d’éviter toute sortie d’erreur. Cette façon de faire présente plusieurs inconvénients :

  • Si la fonction que vous utilisez peut poser problème et générer une erreur, peut-être devriez-vous la corriger ou gérer cette erreur en amont plutôt que de mettre le problème « sous le tapis ».
  • Vous n’avez jamais aucun contrôle sur la situation, même en environnement de développement, ce qui met potentiellement en danger tout le reste du code.
  • Le coût sur les performances et la consommation de mémoire est très important (par rapport au bénéfice obtenu).

Pour prouver ce dernier point, voilà par exemple un test qui met en œuvre une fonction de conversion que j’avais trouvé dans les commentaires de la documentation de PHP :

Comme vous le voyez, la fonction round() est préfixée d’un @ (dont l’intérêt est sans doute plus que discutable, mais ce n’est pas le débat) : ce script retourne chez moi 103.51 kb. Si j’enlève simplement le @, on tombe à 103.27 kb.

Bien entendu, il s’agit de petits chiffres, mais vous imaginez ce que cela peut donner sur un script plus lourd si vous multipliez les utilisations du @Pour conclure, mieux vaut gérer l’affichage des erreurs de façon globale, vous avez tout à y gagner !

Les textes, illustrations et démonstrations présents sur ce site sont la propriété de leurs auteurs respectifs, sauf mention contraire (photo de la bannière).
Chosesafaire.fr, un site propulsé par Wordpress, vous est proposé par Pierre Quillery & Killian Ebel.

Valid XHTML 1.0 Strict