Je suis tombé sur un code récemment qui a utilisé un gestionnaire d'erreur personnalisé pour transformer toutes les erreurs PHP dans une exception d'application généralisée. Un gestionnaire d'exception personnalisé a également été défini pour loger l'exception s'il s'agissait d'une plage de codes d'erreur particulière. Exemple: Le problème est que j'ai vu des choses comme: qui implique qu'il n'y a pas de distinction entre les erreurs de programmation réelles et " Comportement exceptionnel. Après avoir creusé ultérieurement, j'ai rencontré des parties du code qui ont été conçus autour de l'idée que les erreurs PHP représentaient des comportements "exceptionnels" tels que: ce qui finit par des erreurs d'obscurcissement et de la Conception de l'interface de l'application. Quelle est votre opinion sur la manipulation des erreurs de cette façon? Est-il intéressant de transformer les erreurs natales de PHP dans des exceptions? Que faites-vous dans des situations telles que ci-dessus où une base de code est conçue autour de cette idée?
3 Réponses :
Personnellement, je le fais tout le temps. La seule différence est que dans ma fonction Je changerais le alors, alors vous pouvez "essayer" du code comme ceci: i fait aussi mon gestionnaire d'exception par défaut génère une page d'erreur de serveur 500 . C'est parce que toutes les exceptions doivent être attrapées et si elles ne l'étaient pas, c'est vraiment une erreur de serveur ... juste mon expérience et mon opinion ... error_handler , je vérifie si l'erreur est un e_notice en premier, et je ne jette que si ce n'est pas (je me connecte de toute façon) ... AppException sur quelque chose qui s'étend errorxception ... quelque chose comme: phpruntimeerrorexception s'étend errorexception que vous utilisez que Pour les erreurs PHP ... La raison en est que c'est donc plus lisible (il est plus facile de dire ce qu'est un phpruntimeerrorexception sans avoir à comprendre où il est jeté). L'autre raison, est que le errorexception stockera les informations de génération de ligne / fichier / etc., où il ne serait pas stocké ailleurs (puisque le backtrage commence à partir de la ligne ) ...
Oui que tout cela sonne bien, changeant l'appoint à une exception spécifique à une erreur PHP est ce qui est venu à l'esprit en premier. Bien que je me demande quelle est la différence entre cette solution et générer simplement l'erreur de serveur 500 dans le gestionnaire d'erreur personnalisé sans utiliser d'exceptions pour des erreurs réelles. Aussi, y a-t-il des frais généraux pour le faire de cette façon?
Eh bien, ce n'est pas à propos des frais généraux. Je ne génère que 500 pages d'erreur pour des exceptions non gérées. Il y a assez souvent des moments où j'attrape des erreurs de PHP et poursuivre le traitement. Par exemple, DOMDocument augmentera un avertissement s'il ne peut pas analyser une chaîne XML. Donc, je capture cette erreur et l'utiliser pour déclencher un nettoyage et une répartition du fichier essayer {$ DOM-> loadxml ($ xml); } Catch (PhpruntimeErrorexception $ e) {$ xml = xmlcleaner :: propre ($ xml); $ DOM-> LOADXML ($ XML); } Je ne veux pas exécuter le xmlcleaner , car c'est vraiment assez cher. Donc, je laisse l'erreur php à me dire quand le faire ...
Il y a eu un débat à ce sujet dans la communauté PHP. Je crois que la pensée générale est que les erreurs sont des choses lancées par des fonctions PHP internes et sont des problèmes de codage que vous avez vraiment besoin de réparer; tandis que les exceptions sont des choses que votre code d'application a peut-être besoin de "gérer".
Cependant, certaines des plus récentes extensions SPL (qui ont tendance à être plus orientées objet) utilisent des exceptions pour que les choses auparavant auparavant ont des erreurs lancées, il y a donc une zone grise.
Il y a aussi une classe de base PHP errorexception - http: //www.php .NET / Manual / fr / Class.Erorexception.php qui semble un peu plus facile à utiliser que votre code de code, s'il s'agit d'un itinéraire que vous souhaitez descendre.
C'était aussi ma pensée ... Je pense que la confusion provient du fait qu'il existe de multiples mécanismes de traitement des erreurs et pas de normes réelles. J'ai regardé la classe Errorexception et cela ressemble à une bonne première étape.
Eh bien, pour certains, oui. Comme si vous appelez fopen ($ foo) , vous devez obtenir une erreur car il manque le deuxième param. Mais si vous appelez parse_url ($ url) , et URL est une URL vraiment malformée, vous obtiendrez également un avertissement. Donc, dans certains cas, oui, ils codent des problèmes. Mais il y a un grand nombre de problèmes "d'exécution" qui n'ont rien à voir avec le codage ... il est donc vraiment une question de savoir comment vous voulez gérer vos erreurs (j'aime mes exceptions. Si vous ne le faites pas, c'est assez bien aussi. Tant que vous êtes cohérent et méthodique, c'est tout ce qui compte vraiment à la fin) ...
Bien sûr, je pense que c'est un très bon cas, je pensais des erreurs de programmation strictement, mais cela a plus de sens.
Je convertit tout, y compris les avis à des exceptions. Il n'y a aucune raison de permettre à des exceptions de continuer normalement comme cela. Variable ou décalage non défini? C'est un problème.
>> "Variable ou décalage non défini? C'est un problème." Uuhmm ... Et si les données au décalage sont facultatives?
hah. Je ne me dérange pas quand il y a une tonne de variables pour vérifier. Je fais $ foo = $ _get ['foo']; puis quelque part dans la page si (émetteur ($ foo)) . Qui génère des avertissements mais qui se soucie. :)
@ CHX101 Il est clair que vous n'avez jamais eu à traiter d'un site générant tant de notifications par seconde que vous ne trouvez pas les erreurs réelles. Juste Manipulation Les avis peuvent accélérer un site par une quantité massive. Mais c'est hors du point.
@ADADDINSANE OH Bien sûr que j'ai. Cela dépend également du type de projet avec lequel vous travaillez. Par exemple, vous ne pouvez pas laisser des erreurs et des avertissements ni une sortie système non heurtée lors de la création d'un serveur API. Je pourrais vous raconter une histoire mais c'est aussi hors du point.
Le lien est mort (404).