6.9.14 set_error_handler() Spécifie une fonction utilisateur comme gestionnaire d'erreurs

set_error_handler choisit la fonction utilisateur error_handler pour gérer les erreurs dans un script.

set_error_handler peut être utilisé pour définir votre propre manière de gérer les erreurs durant l'exécution, par exemple pour une application dans laquelle vous devez nettoyer les données/fichiers lorsqu'une erreur survient ou lorsque vous devez déclencher une erreur sous certaines conditions (en utilisant trigger_error ).

Il faut se rappeler que la fonction standard de traitement des erreurs de PHP est alors complètement ignorée. error_reporting n'aura plus d'effet, et votre fonction de gestion des erreurs sera toujours appelée. Vous pourrez toujours lire la valeur de l'erreur courante de error_reporting et faire réagir la fonction de gestion des erreurs en fonction. Cette remarque est notamment valable si la commande a été préfixée par @ .

Notez aussi qu'il est alors confié à cette fonction de terminer le script ( die ) si nécessaire. Si la fonction de gestion des erreurs se termine normalement, l'exécution du script se poursuivra avec l'exécution de la prochaine commande.

Les types d'erreur suivants ne peuvent pas être gérés avec cette fonction : E_ERROR , E_PARSE , E_CORE_ERROR , E_CORE_WARNING , E_COMPILE_ERROR , E_COMPILE_WARNING ainsi que la plupart des E_STRICT d'un fichier lorsque set_error_handler est appelé.

Si une erreur survient avant que le script ne soit exécuté (par exemple un téléchargement de fichier), le gestionnaire d'erreurs personnalisé ne pourra pas être appelé, car il n'est pas encore enregistré.

error_handler

La fonction utilisateur doit accepter deux paramètres : le code d'erreur et une chaîne décrivant le code d'erreur. Depuis, trois paramètres optionnels sont fournis en même temps : le fichier dans lequel l'erreur est survenue, la ligne à laquelle l'erreur est survenue, et le contexte dans lequel l'erreu est survenue (un tableau contenant la liste des symboles lors de l'erreur). La fonction peut être décrite comme ceci :

handler   int   errno ( string   errstr , string   errfile , int   errline , array   errcontext )

errno

Le premier paramètre errno , contient le niveau d'erreur, sous la forme d'un entier.

errstr

Le second paramètre errstr , contient le message d'erreur, sous forme de chaîne.

errfile

Le troisième paramètre, optionnel, errfile , contient le nom du fichier dans lequel l'erreur a été identifiée.

errline

Le quatrième paramètre, optionnel, errline , contient le numéro de ligne à laquelle l'erreur a été identifiée.

errcontext

Le cinquième paramètre, optionnel, errcontext , est un tableau qui pointe sur la table des symboles actifs lors de l'erreur. En d'autres termes, errcontext contient un tableau avec toutes les variables qui existaient lorsque l'erreur a été déclenchée. La fonction de gestion d'erreurs de l'utilisateur ne doit pas modifier le contexte d'erreur.

error_types

Sert de masque pour appeler la fonction error_handler de la même façon que l'option de configuration error_reporting contrôle les erreurs qui sont affichées. Sans le masque, error_handler sera appelé pour toutes les erreurs, quelque soit la valeur de error_reporting .

Retourne une chaîne de caractères contenant le dernier gestionnaire d'erreurs (si il y en avait un) ou NULL en cas d'erreur. Si l'ancien gestionnaire d'erreurs était une méthode d'une classe, cette fonction retournera un tableau indexé avec les noms de la classe et de la méthode.

Version	Description
5.0.0	Le paramètre error_types a été introduit.
4.3.0	Au lieu d'un nom de fonction, un tableau contenant une référence à un objet ainsi qu'un nom de méthode peut aussi être passé au paramètre error_handler .
4.0.2	Trois paramètres optionnels pour le paramètre error_handler de la fonction utilisateur ont été introduits. C'est le nom du fichier, le numéro de ligne ainsi que le contexte.

Gestionnaire d'erreurs avec set_error_handler et trigger_error

L'exemple ci-dessous illustre l'interception d'erreurs internes avec génération d'erreur et son exploitation dans une fonction utilisateur :

• error_reporting
• restore_error_handler
• trigger_error
• error level constants
• information à propos de callback type