[PHP5] EXCEPTIONERROR PACKAGE : TRANSFORMER TOUTES LES ERREURS PHP EN EXCEPTIONS
Teclis01
Messages postés
1423
Date d'inscription
mardi 14 décembre 2004
Statut
Membre
Dernière intervention
29 décembre 2012
-
17 oct. 2007 à 21:29
malalam Messages postés 10839 Date d'inscription lundi 24 février 2003 Statut Membre Dernière intervention 2 mars 2010 - 2 mars 2010 à 10:38
malalam Messages postés 10839 Date d'inscription lundi 24 février 2003 Statut Membre Dernière intervention 2 mars 2010 - 2 mars 2010 à 10:38
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/44423-php5-exceptionerror-package-transformer-toutes-les-erreurs-php-en-exceptions-interceptables
https://codes-sources.commentcamarche.net/source/44423-php5-exceptionerror-package-transformer-toutes-les-erreurs-php-en-exceptions-interceptables
2 mars 2010 à 10:38
Mais l'envie est là!
Je vais essayer de repasser un peu plus souvent...
Ravi d'avoir de tes nouvelles ceci dit, Max :-)
1 mars 2010 à 16:00
25 févr. 2010 à 22:37
Perso, j'ai abandonne le php et j'ai plus tellement le droit de bosser pour le web en open.
25 févr. 2010 à 19:57
Faudrait que je re-poste un peu...ça fait un bail (manque de temps :-().
24 févr. 2010 à 23:05
J'ai lu un peu en travers les commentaires et tiens à dire que le fait qu'il n'ai pas ajouté de chichi pour une classe générique est plus un bien qu'un mal !
Après c'est sur qu'une personne ne connaissant pas grand chose au PHP peut éventuellement se tromper sur l'utilisation de ceci à cause du titre ou d'une explication trop brève, mais une personne ne connaissant pas grand chose au PHP ne cherche généralement pas ce genre de source.
Enfin bref... ^^
10 mars 2009 à 19:21
Tout comme avec la méthode astucieuse aussi de FredT, ou l'exemple avec ob_start() : on peut logger, et afficher un message à destination de l'utilisateur malchanceux. Ce qui peut aussi se faire de tout un tas de manière sans toucher au script PHP.
On parle là de 2 choses différentes : gérer les erreurs dans le flux d'un script, et logger les erreurs (pas forcément dans un fichier!) mettant fin à ce flux. J'insiste :-) Le but de ma source n'est pas de logger (on peut aussi hein, je le recommande même vivement), mais de récupérer les erreurs récupérables dans un bloc try catch, afin de gérer les "exceptions" survenues dans un traitement. Pas nécessairement d'arrêter ce traitement.
Bref, ces astuces sont très intéressantes, mais on ne parle par contre pas de la même chose.
10 mars 2009 à 11:40
Par contre, il ne doit pas être possible de recup l'erreur à moins d'aller lire fichier de log (ce qui devient compliqué, erreur simultanée) le processus étant différent. ce que tu peux faire avec register_shutdown_function()
10 mars 2009 à 10:12
heu... pas pour faire de la pub, mais j'vois qu'y a la des experts en errors.
J'ai pas eu le temps d'exploiter et tester suffisemment (pas fait de prog pendant plus de 10 mois l'année dernière en fait) une astuce que j'ai trouvé, et qui me parraissais plus qu'intéressante pour être avertit au plus vite d'une erreur non catchable, sans devoir recourir à la consultation des logs.
la source : TRAITER-ERREURS-PHP-GRAVES-NON-INTERCEPTABLES_45321
Désolé rien à voir avec un beau code POO, mais si vous passez par là, malgré plus de 3000 visites j'ai pas eu de commentaires constructif qui pourrait faire évoluer le truc...
10 mars 2009 à 09:53
Enfin voilà, pour les commentaires que j'ai sité (les 2 derniers cad les 2 plus récents) ils n'utilisent pas de trigger mais register_shutdown_function en précisant bien que c'est seulement pour les runtimes error, ou alors les buffers d'affichages. Ce sont les commentaires de Marcelius et de wfinn à l'adresse http://us2.php.net/manual/fr/function.set-error-handler. Alors savoir si on peut traiter cette erreur avec un gestionnaire personnalisée (je ne parle pas de trigger ou de set_error_handler d'erreur), je n'ai pas testé mais je vais le faire pour register_shutdown_function qui semble la méthode la plus propre et la plus aisée à mettre en place.
9 mars 2009 à 19:11
Ensuite, non, je n'avais pas lu les 2 derniers commentaire, mais je n'y vois aucune solution pour intercepter des erreurs fatales. Qui sont de niveau E_CORE si mes souvenirs sont bons (je n'en suis pas sûr et j'ai la flemme d'aller chercher). Un trigger_error() est une erreur utilisateur. E_USER_XXX, le fonctionnement est différent puisque c'est via PHP qu'on la lance. Une erreur fatale PHP est une erreur qui risque de provoquer l'instabilité du système (dixit la doc) et donc qui arrête immédiatement PHP. C'est pourquoi rien ne peut se passer APRES cette erreur. Or, un gestionnaire d'erreur intervient forcément APRES qu'une erreur ait été lancée.
Si tu regardes bien le dernier code, tu verras que le gars utilise trigger_error() sans autre paramètre que le message d'erreur pour balancer son erreur.
Le 2d paramètre est le niveau d'erreur E_USER_XXX; par défaut, il s'agit dune "notice". Et que mon code les gère.
Le DP strategy permet d'adopter une stratégie en fonction d'un contexte. En l'occurrence il s'adapte bien ainsi : on adopte telle ou telle classe en fonction de l'erreur interceptée. Il ne faut pas aller chercher plus loin que ça. Il peut se complexifier (je parle du design pattern en question), mais la base est celle-là. Le traitement des données d'un formulaire en est un autre exemple: on ne traitera pas un email de la même manière qu'un âge, car le contexte est différent. On va donc adopter une stratégie différente pour traiter l'un et l'autre.
9 mars 2009 à 10:43
9 mars 2009 à 10:33
As-tu lu les 2 derniers commentaires de la fonction set_error_handler() sur la page de php.net (d'ailleurs méthode très astucieuse, surtout pour le dernier commentaire)? Ce n'est pas mon code de pro mais celui des autres mais cela n'empêche que tous les erreurs peuvent-être interceptés mais le problème n'est pas là. Je pensais que ce site était fait pour s'amuser et apprendre et non descendre les autres, ce que j'ai peut-être fait à votre égard mais suite à des commentaires de votre part plus que limite, encore une fois à mon sens.
A plus
6 mars 2009 à 20:05
dans un langage qui parse correctement (avec une grammaire), l'execution intervient apres l'etape du parsing (parsing ~= generation d'un arbre syntaxique)
si il y a un parse error, c'est que la syntaxe du php n'est pas respectee, il est donc impossible d'executer.
(et si les erreurs de fonction non definies ne sont pas detectes entre le parsing et l'exec, c'est simplement parce-que l'instruction include permet de definir de nouvelles fonction en live, et comme include n'est pas une instruction preprocesseur, alors cette verification est impossible. Ajoutons a cela les fonctions genre eval, create_function, etc... et les facons louches d'appeller une fonction 'func_name'($param1, $param2); et ca devient inverifiable. )
appeller une fonction non definie segfault en C, appeller une fonction virtuelle pure en Cpp fait aussi le meme resultat.
bref, ne pas pouvoir les catcher est tout a fait normal, faire differement serait porc voir inconscient.
6 mars 2009 à 19:45
Ouais. Tout à fait d'accord avec toi. Et toi...?
6 mars 2009 à 19:44
Parce que moi, j'essaye :
<?php
function ook() {
echo 'ook';
}
set_error_handler('ook');
setBin();
?>
Ca fait pas "ook" :-(
Et dieu sait que j'aime les "ook" (ceux qui connaissent comprendront).
6 mars 2009 à 19:11
@GR43 donc : non, set_error_handler() n'intercepte pas les erreurs fatales, sauf celle de niveau E_RECOVERABLE_ERROR, ce que j'ai bien précisé; et à l'heure où j'ai fait ce script, la version PHp que j'utilisais ne connaissait pas cette constante, d'où mon notHandledYet.
Je te renvoie à la doc de la fonction que tu cites, qui le dit très clairement:
"E_RECOVERABLE_ERROR (entier) : Erreur fatale qui peut être captée. Ceci indique qu'une erreur probablement dangereuse s'est produite, mais n'a pas laissé l'engin Zend dans un état instable. Si l'erreur n'est pas attrapée par un gestionnaire d'erreur défini par l'utilisateur (voyez aussi set_error_handler(), l'application arrête prématurément comme si cela était une E_ERROR."
Pour les design patterns, même si je n'y ai pas particulièrement réfléchi en écrivant cette source, j'ai en effet suivi naturellement le design pattern strategy. On utilise très souvent des design patterns sans réellement y penser, car ce sont des structures logiques et évidentes. C'est bien leur but d'ailleurs; on y vient donc souvent lorsqu'on crée un code correctement pensé, MEME sans explicitement vouloir en appliquer un. Et c'est normal.
Alors oui, tu t'emballes, et parles un tantinet trop vite; mais avoir le sang chaud, c'est une question de caractère, et ça n'est pas franchement criticable si la personne au sang chaud sait aussi s'auto-critiquer par moment :-)
Quant à la note...moi, perso, je m'en fiche (pour rester poli); je ne poste pas des codes pour avoir de bonnes notes ou la reconnaissance de mes pairs : j'ai passé l'âge, et je sais ce que je vaux. J'en ai même fait mon métier avec un succès certain.
Je poste quand je pense qu'un code que je peux poster (de moins en moins, la plupart de mes codes étant purement professionnels maintenant) peut en aider certains, que ce soit pour lire le code et en apprendre certaines choses, ou l'utiliser.
6 mars 2009 à 03:23
Je cite, sans donner les noms, ils se reconnaîtront :
Ca me parait assez logique si tu réflêchis 2 secondes...une erreur fatale engendre une instabilité de PHP. Avant de noter un code, faudrait voir à se renseigner un peu sur le fonctionnement de php :-)
@Celeg : Pfff c'est du grand n'importe quoi de mettre 4/10 à un code comme celui-ci ! Bon en même temps vue le commentaire, on peut voir que tu n'as rien compris au code et que tu as du noté à l'arrache -_-"
celeg, ton commentaire revient a dire : " quand je tape un poeme et non mon code, php ne marche plus !"
Après ces commentaires, je n'ai pas lu le reste me doutant que cela ne pouvait s'améliorer.
Quelle condescendance les rois du php surtout quand on a tord. En effet, on peut capturer des erreurs fatales (voir commentaire sur php.net fonction set_error_handler()) surtout que pour certains qui se prennent pour des pros ce n'est pas la première fois qu'il raconte n'imp.
Je m'emballe et je rentre dans votre jeu, désolé, mais bon apprenez la modestie et soyez humble la prochaine fois dans vos réponse surtout que qq soit ces connaissances on peut tjs se tromper et tous le monde n'est pas obligé d'apprécier vos sources. Et puis vous n'êtes plus à l'école pour vouloir tjs obtenir des bonnes notes.
En parlant de la source, il y a des idées sympa mais elle est pas non plus fantasmagorique et je ne vois pas non plus le rapport avec les design patterns
2 janv. 2008 à 14:13
A mon sens, soit on utilise les exceptions et on n'oublie donc pas de faire des try, soit on n'est pas sûr de ses blocs try catch et on n'utilise donc pas les exceptions.
Pour ce qui est du notice qui va du coup arrêter le script, bah oui. En même temps, un simple notice peut provoquer de gros dégats aussi...c'est un choix disons. Si toi, tu veux que les erreurs de type notice ne fassent rien, eh bien il te faut écrire un petit gestionnaire d'erreur personnalisé, simplement. En fait, ce code là peut servir de basse, il est TRES simple d'ajouter un niveau d'erreur à intercepter (comme le error_reporting, en somme) en modifiant à peine la classe exceptionErrorHandler et en lui permettant de ne jeter une exception QUE si on est au-dessus du niveau d'erreur prescrit, par exemple.
Pour l'API Reflection, non, je ne vois pas comment elle pourrait déterminer ça. Ce n'est pas son but.
2 janv. 2008 à 11:13
Je compte utiliser ce package, pour attraper les erreurs de la meme manière que les esceptions.
Mais je reviens sur l'idée de CALAK, Y a un truc qui me chagrine beaucoup. L'erreur reste humaine: on peut tres bien oublié de placer son p'tit try...catch... là ou il fallait.
Et Oups, ... ce qui me dérange, c'est qu'une simple Notice par exemple, hum... elle se transforme en fatal Erreur. l' Exception_Handler stop purement et simplement le script, (même s'il est personnalisé) au lancement de la malheureuse Exception lancée avec un niveau Notice, mais oublié d'attrapé .
Suggestion, je sorts de mon domaine de compétence, est-ce que la "Reflection" pourrait permettre de savoir si la cause d'erreur est dans un bloc try{} ou non? Voir un autre moyen?
Si non, au lieu de lancé une Exception, on pourrait faire autre chose ou ne rien faire.
Hum... je suis compliqué, et difficile mais bon, j'aime bien aller au fond des choses.
1 déc. 2007 à 11:35
s'il y en a qui lisent ce commentaire... ;-)
Ce package a été nomminé aux Innovation Awards sur phpclasses.org
http://www.phpclasses.org/browse/package/4188.html
Votez pour moi ;-) Merciii !!
26 oct. 2007 à 20:33
rapide :
$severity est bien le niveau d'erreur. Il renvoie la valeur de la constante. Par exemple, 8 correspond au niveau E_NOTICE.
Le principe est donc le même, sauf que la classe built_in ne fait que renvoyer le niveau d'erreur, elle ne s'en sert pas.
$severity correspond au $errno de la doc php pour set_error_handler().
Pour les exceptions, on passe d'abord le message. C'est tout.
Pour le switch case, désolé, je préfère toujours scinder en plusieurs classes afin de permettre de personnaliser chaque classe plus facilement que de faire un long switch case. Le code est bien plus lisible et bien plus facile à manipuler ainsi.
26 oct. 2007 à 16:24
Maintenant, t'as peut-être foutu ça dans une autre classe (même si je pense que sa place est ici...)
Pour ErrorException, à mon sens, elle trouve toute son utilisation dans ce contexte aussi ^^
Et pour le coup de gèrer les exceptions selon leur type, il est tout à fait possible de faire un:
try { // Some code here } catch ( Exception $e ) { switch ( $e->getCode() ) { case E_USER_WARNING: //... break; case E_USER_ERROR: //... break; //.... } }Après, ça reste une question de gout ;)
Pour en revenir sur ErrorException:
Mais alors, quelle est la différence entre code et severity ?
Attend, je viens peut-être de tilter sur un truc ^^;
quand tu fais ton $e = new Exception([message], [code]);
ton [code], ce n'est pas une constante type E_USER_ERROR ?
Du coup, cette propriété me semble bcp moins utile >_<
Enfin, ... si on veut
Au fait, le lance une update de Prototype, dès qu'elle sera up, (ou que tu l'auras mise up :P) rejettes-y un coup d'oeil.
Certe, les exemple sont pas encore développés à 100% mais tu devrais mieux t'y retrouver ^^
25 oct. 2007 à 23:30
25 oct. 2007 à 23:13
try {
// bla bla
} catch(verySpecificExceptionType $e) {
// traitement très spécifique pour les exceptions très spécifiques
} catch(specificExceptionType $e) {
// traitement spécifique pour les exceptions spécifiques
} catch(nearlyGenericExceptionType $e) {
// traitement presque générique pour les exceptions presque génériques
} catch(Exception $e) {
// traitement pour tous les autres types d'exceptions
}
On ne traitera pas forcément une erreur de type notice (E_NOTICE) et une erreur de type erreur "fatale" utilisateur (E_USER_ERROR).
25 oct. 2007 à 22:48
Si j'ai choisi d'ajouter le support de toutes les erreurs, c'est juste au cas où C'est aussi pour ça que ma classe supporte les E_RECOVERABLE bien que je n'ai jamais vu de fonction les lançant, et implémente une classe dépotire "errorNotHandledYet", afin de tout couvrir. Au cas où...
Encore une fois, cette classe trace les erreurs...Après, tu fais ce que tu veux des traces. Moi, selon les applicatifs, je les logge, je me les envoie par email, ou je les oublie...ça n'st pas à moi, et donc pas à ma classe, de décider ce que tu veux faire de tes erreurs. Cette classe n'est pas là pour ça, elle est juste là pour t'aider à les relever, ces erreurs, ou plutôt, à les intercepter et à travailler dessus! Je ne sais pas toi, mais même sur mes serveurs de prod, je suis en error_reporting(E_ALL). Alors me permettre de gérer les erreurs (warning, notice etc) comme des exceptions, c'est carrément un grand pas en avant. Ce que je fais ensuite ne regarde que moi, et dépend du contexte de mon applicatif. Et c'est la même chose pour vous.
Une classe traitant des données, ça traite des données. Si par la suite tu as envie d'insérer ces données traitées dans une bdd, ben tu utilises une autre classe, un autre outil. Tu ne vas pas te plaindre parce que ta classe traitant les données ne les intègre pas en plus dans une bdd? C'est pareil ici. Cette classe ne fait QUE intercepter les erreurs comme des exceptions. Point barre. Ce n'est pas un manque ou un oubli qu'elle n'aille pas plus loin, c'est voulu et parfaitement assumé. Et je réfuterai toute demande allant dans le sens contraire parce que ces demandes n'ont pas lieu d'être.
Tu te plains de ta distribution Linux parce qu'elle ne fait pas le café en built-in, toi? Moi, si je veux qu'elle fasse du café, je trouve un svcript "domotique" à brancher sur ma cafetière, je ne blâme pas ma distrib Linux.
Je ne m'appelle pas Google : je ne suis pas un moteur de recherche permettant e, plus même si ça n'a aucun rapport d'afficher des cartes du monde. Je suis une classe, ou plutôt un ensemble de classes permettant d'intercepter des erreurs. Point.
@Calak => je ne connaiis pas cette "ErrorException"...t'as trouvé ça où??
J'ai effectiovement déjà répondu pour les classes "typées". Je ne vois pas quoi ajouter :-) Sauf qu'encore une fois, mon but est de faire simple et efficace : cela marche comme je le voulais en l'état. Et c'est facilement modifiable, réimplémentable, étendable. Le but était là. Pas plus. Pas moins.
Je n'intercepte que les erreurs, oui...ben oui. Moi, j'utilise cette classe avec tout un ensemble d'autres classes dédiées à la gestion des erreurs. Et parmi elle, il y a des classes spécialisées, dédiées à MES autres classes, au contexte spécifique de l'applicatif, et avec aussi un output spécifique à l'applicatif. Ca, c'est de l'ordre du contextuel...ça n'aurait rien à faire dans cette classe. Vraimen t, j'insiste...ne confondait pas un applicatif et un outil...cet ensemble de classes est un outil. T'as la mchaine, différentes mèches...après, que tu veuilles t'en servir pour mettre un tableau au mur, ou des pitons dans un mur d'escalade...ça, c'est TON utilisation. Moi je suis Black&Decker, et je ne fais pas les trous à ta place.
Je ne vois pas ce que ferait la SPL là-dedans ? Elle possède ses propes exceptions, bon...ben voipà; c'est fait, lol, tu veux que j'ajoute quoi ? Un try catch() sur un itérateur fonctionne très bien. Ma classe n'a strictement aucun rapport avec la SPL là...je ne vois pas ce que tu entends par là?
@Audayls => merci :-)
@Coucou => décidément, je suis flatté :-) Merci.
@Calak again => je viens de trouver en effet quelques références à la classe dont tu parles. Elle fait partie de la SPL. severity simule le niveau d'erreur d'après ce que j'ai pu comprendre (il y a peu de docs sur cette classe). Et la classe est on ne peut plus basique. Comme quoi...ce n'était pas une si mauvaise idée... ;-)
25 oct. 2007 à 22:13
=>
c'est rare que je dise ca, alors profitez en...
pour une fois, j'ai envie de copier coller cette source directement dans mon framework, sans y apporter la moindre modif...
25 oct. 2007 à 21:34
"Envoi moi un mp si tu souhaite continué la discu, pour ne pas polué plus tes commentaires." bah perso je trouve pas que çà pollue ! Bien au contraire =)
J'ai surtout envie de voir si tu vas trouver un argument potable parce que désolé de te dire çà mais pour le moment ton argumentation c'est le grand vide... Tu te contentes de jouer avec les mots en disant "Oui mais tu n'avais pas préciser qu'on ne pouvait pas récuperer les erreurs irrécupérables". Alors oui le méchant Malalam n'a pas du tout précisé non plus que son code ne faisait ni le café ni les pizzas (je dis pizza parce que j'ai faim =P).
Sinon je dirais qu'il ne faut pas faire de code "pret à pomper" en ajoutant tous les systèmes de log etc... parce que le but de la POO c'est de séparer et surtout il n'y aurait pas le côté instructif. Dans cet état, il faut lire et comprendre cette source pour ensuite l'adapter à sa façon pour en faire ce que bon nous semble.
Même si mon commentaire n'a pas de grand interet pour le code PHP de cette source, je pense montrer que cette source est bonne et mérite une bonne note, parce que pour faire de bonnes choses avec il faut la comprendre et ainsi améliorer son niveau en PHP.
@Calak :
Si chaque type d'erreur est séparé c'est pour que tu puisses faire des actions différentes selon les erreurs. Ainsi le codage et la mise à jour de ton code seront beaucoup plus simple ;-)
25 oct. 2007 à 15:56
En l'état, je mettrais 8/10 pour une raison bien précise:
Toi qui prône l'utilisation de la SPL tu n'en tire pas parti (je parle de RuntimeException, LogicException, etc... )
Il aurait été intelligent, à mon sens, de les utiliser afin, entre autre, de démontrer leur utilité. A noter aussi qu'une classe "Exception" pour la gestion des "error" existe en interne dans php, mais n'est pas documentée. Et son nom? ErrorException ^^ (d'ailleur, en parlant de cette dernière, il y a une propriété et une méthode dont je ne comprend pas encore l'utilité: severity/getServerity() )
je n'ai encore vu aucune classe qui en tirait parti.
De plus, ici, pourquoi faire une classe pour chaque "type" d'erreur? (notice, warning, error) ce type étant stocké dans l'attribut code?
J'ai bien vu que tu t'es expliqué sur le sujet, mais alors pourquoi ne pas simplement faire de ces classes des classes génériques pour la gestion des exception?
Ici tu ne catch que les erreurs, il serait peut-être intéressant de pousser le concepte un rien plus loin (sans toutes-fois développer toute une classe de debugging ^^)
Voila, si tu règle tout ça (du moins pour le ErrorException), tu meriteras un 10/10, en attendant, je ne note pas ;)
Pascal Blétard
25 oct. 2007 à 11:14
Quand je marque ne sont pas capturés par exemple: E_CORE_WARNING, E_COMPILE_WARNING j'ai bien précisé pour set_error_handler, donc en quoi je me trompe ? J'ai juste souligné que tous les warnings ne sont pas capturé par set_error_handler. Je ne confond pas capture d'erreur et debugger
J'ai écrit "avec en fonction" c'etait "une".
c'est à dire une fonction qui traite ca à part. Une classe static qui capture l'erreur filtre le tracage des erreurs utilisateurs, Alerte specifique (et pas celle d'analyse ni du noyau on est ok) qui la transmet a cette fonction qui se chargera d'ecrire les erreurs dans un journal d'evenement et de les afficher ou pas à l'ecran.
Pour parent::__construct($sErrStr, $cErrno); je ne l'avais pas vu, et toute mes excuses.
Pour $Type apres tes explications, je vois un peu mieu ou tu veux en venir mais cela aurait justement augmenté l'interet de ta classe si tu avais approfondit se segment de code.
Envoi moi un mp si tu souhaite continué la discu, pour ne pas polué plus tes commentaires.
25 oct. 2007 à 09:36
Etendre ma classe avec $sType permet de modifier facilement les différentes classes. SI je veux ajouter des méthodes propre à chaque type d'erreur, je peux le faire facilement. Ce n'est pas pour le style, c'est pour coder correctement et utiliser la POO comme elle doit l'être : c'est à dire surtout pas coder toute un "applicatif" dans une seule classe toute puissante...pourquoi, de plus, me trimballerais-je des propriétés dont je n'ai pas besoin ? Si j'ai une erreur de type warning, je veux afficher (puis éventuellement faire un traitement spécifique, à chacun ses besoins) que ce niveau d'erreur, donc je n'ai pas besoin de variables contenant d'autres niveaux d'erreur.
Personnellement, toutes les données de traçage sorties me servent. La seule qui est parfois inutile, c'est le context, qui est du coup optionnel (ce qui fait que tu peux ne pas l'afficher...). C'est le cas du serveur, par exemple...
Ensuite, c'est un package servant uniquement à intercepter les erreurs php, ce n'est pas un debugueur, ne confonds pas! Là, tu me parles d'un débugueur. Ce package peut servir de base pour créer ses logs ou autre, à chacun sa manière. C'est exactement à cela qu'il sert. Les classes sont des outils, ce ne sont pas des applicatifs. En aucun cas je n'ai parlé d'applicatif complet, j'ai bien préciser : elle est destinée à intercepter les erreurs! Je n'ai pas dit : loggez vos exceptions dans un fichier, envoyez-vous les par mail, etc. Si tu veux un debugueur, j'en ai fait un il y a quelques temps, il est sur ce site.
Quand tu ne mets pas de constructeur à une classe héritant d'une autre, le constructeur parent est automatiquement appelé. Pour info. Et tu remarqueras (enfin apparemment non, mais je te le précise) que ma classe parente à toutes mes classes "d'erreur", elle, fait appel au constructeur de la classe built-in Exception::__construct().
Au fait, E_CORE_WARNING, donc, si tu connais PHP, est un warning du coeur de PHP, de son code à lui, elle est lancée avant l'interprétation du code. Une fonction écrite en PHP ne PEUT et ne DOIT pas provoquer ce genre d'erreur. Et c'est le cas de toutes les E_CORE_*.
Encore une fois, est-il vraiment nécessaire de préciser l'évidence...?
25 oct. 2007 à 08:29
En gros oui, je suis desolé mais bon je l'ai noté ainsi, j'ai le droit de ne pas aimé ce code ? Ah première vu nan !
Faut préciser que l'ajout de commentaire n'est autorisé quand cas de bonne note & remarque.
malalam me dit : set_error_handler ne capture que les warning, notice, et toutes les erreurs utilisateurs, devrait il préciser pas tout les warning déja, bah oui ne sont pas capturés par exemple: E_CORE_WARNING, E_COMPILE_WARNING en autre. Bah excuse moi, mais la doc php, je la connais un peu, c'est pour ca que j'ai testé ta classe , comme y avait marqué dans ta description "transformer toutes les erreurs PHP en exceptions interceptables" et de voir en parcourant ton code que tu mentionne justement les erreurs de type Fatal Error etc.. je me suis dit qu'il existait "peu etre" un moyen de levé cette limitation.
Etendre des classe juste pour $sType quel interet ? Ecriture de style ? mais dans la pratique quel interet?
Puis lorsque je vois les informations retournées lorsque qu'une erreur est capturé par la classe,
on recoit une quantités de données avec le tracage, mais la motié des données ne servent pas. Et en plus il y a des données redondante, ca aurait peu etre été bien de filtrer les informations, savoir d'ou est partie l'erreur et ou elle à provoqué la capture de l'erreur. Parce que par exemple si tu affiche une variable indéfini, j'ai pas forcément besoin de savoir sur quel serveur je tourne pour me dire que j'ai oublié de définir une variable, par contre si cette valeur est dans une classe inclus dans script c'est peu etre mieu de localisé ca. Moi j'ai fait comme ca quand j'ai étendu ma classe Exception avec en fonction du mode dev/prod la possibilité d'afficher les erreur ou pas et de les l'écrire dans un fichier log.(Rien d'exceptionnel)
Donc je n'ai pas aimé oui je l'avou , car je ne vois pas ce qu'elle apporte par rapport à d'autre classe. Je l'ai noté pas seulement sur quelque chose que je savais déja c a d sur la capture de telle ou telle erreur mais sur l'ensemble. Par exemple dans la doc php, il est noté que
Si une classe étend la classe Exception interne et redéfinit le constructeur,(chose que je crois que fait la classe) il est vivement recommandé qu'elle appelle aussi parent::__construct() pour s'assurer que toutes les données disponibles ont été proprement assignées.
Etendre des classes juste pour $sType je cherche l'intéret... sauf à genérer des lignes de descriptions pour la doc et du code... c'est peut etre beau dans le codage mais en pratique ca apporte peu a mon sens a moin que Malalam avait une idée derrière la tete.
24 oct. 2007 à 20:24
24 oct. 2007 à 20:01
24 oct. 2007 à 19:54
23 oct. 2007 à 21:18
celeg, ton commentaire revient a dire : " quand je tape un poeme et non mon code, php ne marche plus !"
si on pouvait catcher une parse error, ca abaisserait php au niveau du fbsl...
pour comparer au java : une parse error, c'est une erreur de compilation... quand tu compiles, tu ne peux pas lancer de throw, ni de catch puisque ton code ne tourne pas...
23 oct. 2007 à 20:36
Super code made by Boss Malalam, à utiliser impérativement XD
23 oct. 2007 à 00:38
Ca me parait assez logique si tu réflêchis 2 secondes...une erreur fatale engendre une instabilité de PHP. De même les parse error ne peuvent pas non plus être capturées, ou les run time errors, ou les core errors.
Avant de noter un code, faudrait voir à se renseigner un peu sur le fonctionnement de php :-)
22 oct. 2007 à 23:36
20 oct. 2007 à 18:10
Bah pour finir, je me rend compte qu'a peu de chose près ma classe est la même que la tienne :P
En plus, hier, j'ai trouvé une autre méthode pour l'internationnalisation des erreur, j'ai hate de rentrer chez moi pour tester de l'implémenter ^^
Je te montrerai quand ça sera fait :P
18 oct. 2007 à 20:07
Après 1 éclipse de plusieurs semaines , je reviens et trouve une nouvelle interface au portail CS et également des bonnes sources et bons tutos.
bref, je suis ravi, et j'ai envie de me remettre à la quête de bonnes idees de prog. Ces codes là, je pense, mettent beaucoup de gens sur la bonne voie. Cool et merci pour tes contributions et je suis pas faux *** en disant ça!!
18 oct. 2007 à 12:54
@Coucou => wow, je suis flatté, vraiment, je t'ai rarement vu mettre un commentaire de ce genre sur un code! Merci :-) J'ai un peu modifié le bin's, avec la gestion des types d'erreurs...non gérés! Bref, un type générique, au cas où de nouveaux types d'erreurs apparaissent dans PHP. Et la possibilité d'appeler statiquement le error handler, juste histoire de :-)
18 oct. 2007 à 07:07
17 oct. 2007 à 21:29
Si personne se met au pattern design avec ça !