erreurs au-delà de la mise en error_reporting Réprimant (display_errors peut-être?)

Question

Disons que je suis héritant essentiellement un site en qui a beaucoup d'erreurs dans la production, je fais essentiellement un recodage de ce site entierqui pourrait prendre un mois ou deux. Dans certains cas, ce site dépendait des flux de fichiers XML externes qui ne sont plus là, mais le code n'a pas été configuré correctement pour fournir un bon message d'erreur (il existe diverses circonstances similaires) - le client demande qu'au moins ces messages d'erreur disparaissent même si, par exemple, le contenu du fichier xml n'est pas publié, donc nous ne verrons pas les erreurs php et une région vide sur la page (pour que le reste de la page puisse ressembler " bien").

À un moment donné j'ai entendu parler de quelqu'un en utilisant set_error_handler d'annuler certains cas où il n'est pas extrême et j'ai eu l'idée de le mettre en place pour stocker les messages d'erreur dans un fichier/log ou par courriel (et essayer pour ne pas avoir des messages d'erreur en double) essentiellement pour que les utilisateurs finaux ne doivent pas voir ces choses laides.

Je suis à la recherche de conseils de quiconque a réellement fait cela, alors merci d'avance.

Answer 1

Lorsque dans le développement, il est bon d'utiliser

error_reporting(E_ALL); 
ini_set('display_errors', 'On'); 

Vous pouvez donc voir les erreurs immédiatement: il aide à les corriger.

Lorsque sur le serveur de production, vous ne voulez pas d'erreur affiché, donc:

ini_set('display_errors', 'Off'); 

error_reporting peut rester activé: si display_errors est désactivé, les erreurs ne seront pas affichés de toute façon - mais vous peut toujours les avoir connecté à un fichier.

BTW, ceux-ci peuvent être définis dans le php.fichier ini, bien sûr:

• error_reporting
• display_errors

Sur la machine de production, vous voudrez peut-être utiliser log_errors et error_log, si les erreurs sont enregistrées dans un fichier (ce qui signifie vous serez capable de savoir quelles erreurs se sont produites - peuvent être utiles, parfois); bien sûr, n'oubliez pas de vérifier ce fichier de temps en temps ;-).

En sidenote, si vous avez juste une des fonctions/méthodes couple que vous ne voulez pas afficher les erreurs, vous pourriez envisager d'utiliser le @ operator pour masquer les erreurs que ceux qui pourraient déclencher ...

. .. Mais je vous déconseille fortement (sauf dans des cas très particuliers): cela rend le débogage beaucoup plus difficile: les erreurs déclenchées ne sont jamais affichées, pas même sur votre machine de développement!

À mon avis, il est préférable de simplement désactiver display_errors sur la machine de production; cela signifie également qu'aucune erreur ne sera affichée, ce qui est mieux pour les utilisateurs!

Answer 2

Sur votre serveur de production, vous devez avoir les paramètres ini suivants:

ini_set('error_reporting', E_ALL | E_STRICT); 
ini_set('log_errors', true); 
ini_set('error_log', '/tmp/php_errors.log'); // or whatever file is appropriate 
ini_set('display_errors', false); 

En désactivant display_errors, vos utilisateurs ne verront jamais un autre message d'erreur, mais vous pourrez voir les messages d'erreur par regarder dans le fichier journal. Lorsque le re-code est terminé, il ne devrait plus y avoir d'erreurs dans le fichier journal (parce que vous les avez toutes réparées).

Édition: Certains développeurs ont défini error_reporting sur E_ALL^E_NOTICE pour masquer les erreurs. C'est une mauvaise pratique car elle cache des messages sur d'éventuelles erreurs de programmation. Vous devez seulement utiliser E_ALL^E_NOTICE lorsqu'il y a tellement d'avis venant du code existant que vous ne pouvez pas les corriger tous.