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 ).
Avertissement
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.
Avertissement
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.
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.
