Rapport d'erreur
Changement de configuration
Avec PHP 3, le niveau de rapport d'erreur était obtenu en ajoutant les constantes numériques de chaque niveau de rapport. Généralement, on utilisait 15 pour afficher toutes les erreurs, et 7 pour afficher toutes les erreurs hormis les alertes simples.
PHP 4 dispose d'un nombre significativement plus grand de niveaux de rapport d'erreur, et l'analyseur accepte désormais les constantes symboliques destinées à configurer le comportement désiré.
Le niveau de rapport d'erreur doit désormais être explicitement configuré en supprimant les niveaux dont vous ne voulez pas, grâce à la fonction de OU exclusif. Ça a l'air compliqué? Supposons que vous souhaitiez afficher toutes les erreurs, hormis les alertes de style, qui sont repérées par la constante : E_NOTICE. Il suffit d'ajouter la valeur suivante dans le fichier php.ini : error_reporting = E_ALL & ~E_NOTICE. Si vous voulez supprimer aussi les alertes, vous pouvez ajouter la constante appropriée, en la combinant avec l'opérateur OU logique '|': error_reporting= E_ALL & ~( E_NOTICE | E_WARNING ).
Lors de la mise à jour de votre code ou de vos serveurs de PHP 3 à PHP 4, vous devez vérifier ces valeurs de configuration et appeler la fonction error_reporting() ou bien désactiver les nouveaux types d'erreurs, tout spécialement E_COMPILE_ERROR. Ceci peut mener à des documents vides sans aucune possibilité de tracer ce qui s'est produit ou où rechercher le problème.
L'utilisation des anciennes valeurs 7 et 15 est une très mauvaise idée, car elles ne prennent pas en compte les nouvelles classes d'erreurs, y compris certaines erreurs d'analyse. Cela peut conduire à des résultats très étranges, où le script n'affiche plus rien, malgré une erreur d'analyse.
Cela a conduit dans le passé à un grand nombre de rapports de bogues sur l'analyseur, alors que les programmeurs n'étaient tout simplement pas capables de repérer l'accolade manquante dans un fichier requis, car l'analyseur avait la consigne de cacher ces erreurs.
Vérifier votre niveau d'erreur doit être le premier réflexe lorsque vos scripts meurent silencieusement. Le moteur Zend est considéré actuellement comme suffisamment mature pour ne plus causer ce genre de problème aujourd'hui.
Nouveaux messages d'erreurs
Un grand nombre de scripts PHP 3 utilisent des structures qui doivent être considérées comme un très mauvais style, même si elles effectuent bien les tâches qui leur sont affectées, car ces scripts ne sont pas robustes. PHP 4 affichera de nombreux messages d'erreur dans des situations où PHP 3 restera coi. La solution de facilité consiste à supprimer les messages de niveau E_NOTICE, mais c'est une meilleure idée de plutôt corriger le code.
Le cas le plus courant qui génèrera des messages d'alertes est l'utilisation de constantes sans guillemets comme index de tableaux. PHP 3, comme PHP 4, finiront par les interpréter littéralement comme des chaînes, si aucune constante n'est définie à la place. Mais si jamais une telle constante est définie dans une autre partie du code, cela risque de produire des résultats étonnants. Cela peut devenir un trou de sécurité si un pirate arrive à redéfinir les constantes de telle manière que le script lui donne accès à un niveau de droits supérieur. PHP 4 vous signalera tout oubli de guillemets par exemple dans : $_SERVER[REQUEST_METHOD]. Modifier ce code en $_SERVER['REQUEST_METHOD'] rendra l'analyseur heureux, et améliorera grandement votre style et la sécurité du code.
PHP 4 vous signalera les variables ou les éléments de tableaux non initialisés.