Explication détaillée de l'utilisation de la journalisation des erreurs et des exceptions en PHP

Cet article présente principalement l'utilisation de la journalisation des erreurs et des exceptions en PHP. Il analyse plus en détail la différence entre les erreurs et les exceptions en PHP et les compétences d'utilisation correspondantes de la journalisation. Les amis dans le besoin peuvent s'y référer

Les détails sont les suivants :

En ce qui concerne le journal des erreurs du service Nginx + PHP, nous pouvons généralement penser au journal d'accès Nginx, au journal des erreurs et au journal des erreurs PHP. Bien que cela semble être une question très simple, cela implique en fait la configuration de l'application et l'emplacement d'enregistrement du journal. Si vous utilisez apt-get pour l'installer sur un système tel qu'Ubuntu, il dispose de son propre ensemble de fichiers de configuration plus raisonnables. De plus, la configuration dans l'application en cours d'exécution affectera également la méthode et le contenu de la journalisation.

La différence entre les erreurs et les exceptions

Concernant les erreurs et les exceptions, nous pouvons utiliser un exemple simple pour comprendre :

<?php
try {
 1 / 0;
} catch (Exception $e) {
 echo "catched", PHP_EOL;
}

L'exécution de ce petit exemple entraînera directement une erreur "PHP Warning: pision by zero...". La raison est simple : il s’agit d’une erreur logique, pas d’une exception, elle ne peut donc pas être détectée par un essai. De même, si une variable n'est pas définie avant utilisation, un avertissement sera généré au lieu d'être capturé.

Cependant, ce problème a quelques changements dans PHP7. Par exemple, dans l'exemple ci-dessus, j'ai changé / en %, et une fois exécuté dans l'environnement PHP7, j'obtiendrai une invite différente :

PHP Fatal error: Uncaught pisionByZeroError ...

D'après cette astuce, si je modifie les conditions en catch :

<?php
try {
 1 / 0;
} catch (pisionByZeroError $e) {
 echo "catched", PHP_EOL;
}

De cette façon, les erreurs peuvent être capturées normalement et capturées sont sorties.

Pour le premier exemple, si vous remplacez Excepiton par ErrorException, vous pouvez également l'attraper normalement.

Quant à savoir pourquoi le reste et la division sont les mêmes en PHP5 mais la division n'est pas un problème de pisionByZeroError en PHP7 (mon environnement de test est 7.0.4), cela devrait être un BUG.

Enregistrement du journal

PHP lui-même possède les journaux configurables suivants :

① Journal des erreurs php-fpm (php-fpm. conf, enregistre le démarrage et arrêt du processus php-fpm)

② Journal lent de php-fpm (également configuré dans php-fpm.conf, enregistre l'exécution lente)
③ Journal des erreurs php (php. ini pour enregistrer les journaux d'erreurs de l'application)

De plus, Nginx dispose également de deux journaux configurables : le journal des accès et le journal des erreurs. Ces fichiers journaux ont des fonctions différentes et des contenus enregistrés différents. Mais il y a un point à noter : si l'emplacement du journal des erreurs dans php-fpm est configuré, mais que l'emplacement du journal n'est pas accessible en écriture (l'emplacement doit être correct lors de la configuration, car php-fpm le vérifiera au démarrage), sous le conditions de configuration appropriées Le journal des erreurs sera renvoyé à cgi et écrit dans le journal des erreurs de nginx.

Ainsi, lorsque nous rencontrons des problèmes, nos idées générales de recherche sont :

1. Vérifiez le code d'état de la requête dans le journal d'accès Nginx

2. Vérifiez l'enregistrement d'erreur dans le php. journal des erreurs et informations sur la pile
3. Vérifiez le journal php-fpm pour les enregistrements de redémarrage anormaux (cela se produira s'il y a des problèmes de base ou d'extension)

Mais dans les situations ci-dessus, vous constaterez également que ceci il n'y a aucun enregistrement de journal de l'exception levée par le programme mentionné ci-dessus.

Enregistrement d'exception

L'exception est différente de l'erreur À proprement parler, il s'agit d'une exception de la logique d'application plutôt que d'une erreur. Elle peut être déclenchée manuellement via une logique de programme raisonnable. . Mais dans la plupart des cas, les exceptions doivent également être enregistrées, telles que les exceptions déclenchées par l'impossibilité de se connecter à la base de données ou une mauvaise utilisation du framework. Nous devons utiliser des journaux pour localiser le problème et le traiter en temps opportun.

PHP fournit deux fonctions pour personnaliser les méthodes de gestion des erreurs et des exceptions :

① set_error_handler

② set_exception_handler

Vous pouvez donc utiliser la fonction set_exception_handler La méthode injectée intercepte toutes les exceptions et les enregistre.

monolog est une excellente bibliothèque d'enregistrement d'exceptions et est également basée sur la norme PSR-3. Il est également utilisé par défaut dans Laravel et Symfony pour enregistrer les exceptions. Si nécessaire, vous pouvez également envisager de l’introduire dans vos propres projets.

Résumé : Ce qui précède représente l'intégralité du contenu de cet article, j'espère qu'il sera utile à l'étude de chacun.

Recommandations associées :

phpExplication détaillée des méthodes abstraites et des instances de classe abstraites

Explication détaillée de l'utilisation du mot-clé final en php

Utilisation des mots-clés statiques et const en php

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!