begin process at 2010 03 11 17:41:21
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

Divers

 > [PHP5] EXCEPTIONERROR PACKAGE : TRANSFORMER TOUTES LES ERREURS PHP EN EXCEPTIONS INTERCEPTABLES

[PHP5] EXCEPTIONERROR PACKAGE : TRANSFORMER TOUTES LES ERREURS PHP EN EXCEPTIONS INTERCEPTABLES


 Information sur la source

Note :
8,83 / 10 - par 6 personnes
8,83 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Divers Classé sous :exceptions, erreur, transformation, gestionnaire, handler Niveau :Expert Date de création :17/10/2007 Date de mise à jour :01/01/2008 10:15:33 Vu / téléchargé :6 738 / 261

Auteur : malalam

Ecrire un message privé
Site perso
Commentaire sur cette source (43)
Ajouter un commentaire et/ou une note

 Description

Ce package permet de transformer toutes les erreurs PHP en exceptions interceptables.
En clair, sur toutes les fonctions PHP (ou vos fonctions renvoyant des erreurs utilisateurs par exemple via trigger_error()), vous pouvez grâce à ce package faire des try catch.

Le code est documenté, et un exemple est disponible dans le fichier index.php.

Source

  • <?php
  • /**
  • * @package package.exceptions.errors
  • * @author Johan Barbier <barbier_johan@hotmail.com>
  • * @version 20071017
  • * @desc package transforming all php errors into catchable exceptions
  • *
  • */
  • /**
  • * @name exceptionErrorGeneric
  • * @desc Generic exceptionError class. Overload Exception::__toString() method and Exception::__construct() method
  • *
  • */
  • abstract class exceptionErrorGeneric extends Exception {
  • /**
  • * @desc Error type
  • *
  • * @var string
  • */
  • protected $sType;
  • /**
  • * @desc Error file
  • *
  • * @var string
  • */
  • protected $sErrFile;
  • /**
  • * @desc Error line
  • *
  • * @var int
  • */
  • protected $iErrLine;
  • /**
  • * @desc Error context
  • *
  • * @var mixed
  • */
  • protected $mVars;
  • /**
  • * @desc is context enabled or not
  • *
  • * @var boolean
  • */
  • protected $bContext;
  • /**
  • * @desc constructor
  • *
  • * @param constant $cErrno
  • * @param string $sErrStr
  • * @param string $sErrFile
  • * @param int $iErrLine
  • * @param mixed $mVars
  • * @param boolean $bContext
  • */
  • public function __construct($cErrno, $sErrStr, $sErrFile, $iErrLine, $mVars, $bContext = false) {
  • parent::__construct($sErrStr, $cErrno);
  • $this->sErrFile = $sErrFile;
  • $this->iErrLine = $iErrLine;
  • $this->mVars = $mVars;
  • $this->bContext = $bContext;
  • }
  • /**
  • * @desc Exception::__toString() overloading
  • *
  • * @return string
  • */
  • public function __toString() {
  • $sMsg = '<strong>'.$this->sType.'</strong><br />';
  • $sMsg .= $this->getMessage().'['.$this->getCode().']<br />';
  • $sMsg .= '<em>File</em> : '.$this->sErrFile.' on line '.$this->iErrLine.'<br />';
  • $sMsg.= '<em>Trace</em> :<br />'.$this->getTraceAsString().'<br />';
  • if(true === $this->bContext) {
  • $sMsg.= '<em>Context</em> :<br />'.print_r($this->mVars, true);
  • }
  • return $sMsg;
  • }
  • }
  • /**
  • * @desc exceptionErrors for Fatal errors
  • *
  • */
  • class exceptionErrorError extends exceptionErrorGeneric {
  • protected $sType = 'Fatal error';
  • }
  • /**
  • * @desc exceptionErrors for Warnings
  • *
  • */
  • class exceptionErrorWarning extends exceptionErrorGeneric {
  • protected $sType = 'Warning';
  • }
  • /**
  • * @desc exceptionErrors for Parse errors
  • *
  • */
  • class exceptionErrorParseError extends exceptionErrorGeneric {
  • protected $sType = 'Parse error';
  • }
  • /**
  • * @desc exceptionErrors for Notice
  • *
  • */
  • class exceptionErrorNotice extends exceptionErrorGeneric {
  • protected $sType = 'Notice';
  • }
  • /**
  • * @desc exceptionErrors for Core errors
  • *
  • */
  • class exceptionErrorCoreError extends exceptionErrorGeneric {
  • protected $sType = 'Core error';
  • }
  • /**
  • * @desc exceptionErrors for Core warnings
  • *
  • */
  • class exceptionErrorCoreWarning extends exceptionErrorGeneric {
  • protected $sType = 'Core warning';
  • }
  • /**
  • * @desc exceptionErrors for Compile errors
  • *
  • */
  • class exceptionErrorCompileError extends exceptionErrorGeneric {
  • protected $sType = 'Compile error';
  • }
  • /**
  • * @desc exceptionErrors for Compile warnings
  • *
  • */
  • class exceptionErrorCompileWarning extends exceptionErrorGeneric {
  • protected $sType = 'Compile warning';
  • }
  • /**
  • * @desc exceptionErrors for User errors
  • *
  • */
  • class exceptionErrorUserError extends exceptionErrorGeneric {
  • protected $sType = 'User error';
  • }
  • /**
  • * @desc exceptionErrors for User warnings
  • *
  • */
  • class exceptionErrorUserWarning extends exceptionErrorGeneric {
  • protected $sType = 'User warning';
  • }
  • /**
  • * @desc exceptionErrors for User notices
  • *
  • */
  • class exceptionErrorUserNotice extends exceptionErrorGeneric {
  • protected $sType = 'User notice';
  • }
  • /**
  • * @desc exceptionErrors for Strict errors
  • *
  • */
  • class exceptionErrorStrictError extends exceptionErrorGeneric {
  • protected $sType = 'Strict error';
  • }
  • /**
  • * @desc exceptionErrors for not handled yet errors
  • *
  • */
  • class exceptionErrorNotHandledYet extends exceptionErrorGeneric {
  • protected $sType = 'Not handled yet';
  • }
  • /**
  • * @desc error handler, calling correct exceptionError type
  • *
  • */
  • class exceptionErrorHandler {
  • /**
  • * @desc translation between context error and exceptionError type of class
  • *
  • * @var array
  • */
  • public static $aTrans = array (
  • E_ERROR => 'exceptionErrorError',
  • E_WARNING => 'exceptionErrorWarning',
  • E_PARSE => 'exceptionErrorParseError',
  • E_NOTICE => 'exceptionErrorNotice',
  • E_CORE_ERROR => 'exceptionErrorCoreError',
  • E_CORE_WARNING => 'exceptionErrorCoreWarning',
  • E_COMPILE_ERROR => 'exceptionErrorCompileError',
  • E_COMPILE_WARNING => 'exceptionErrorCompileWarning',
  • E_USER_ERROR => 'exceptionErrorUserError',
  • E_USER_WARNING => 'exceptionErrorUserWarning',
  • E_USER_NOTICE => 'exceptionErrorUserNotice',
  • E_STRICT => 'exceptionErrorStrictError'
  • );
  • /**
  • * @desc is context enabled or not
  • *
  • * @var boolean
  • */
  • public static $bContext = false;
  • /**
  • * @desc constructor, optional bContext boolean can be given if you want context to be displayed or not
  • *
  • * @param boolean $bContext (optional, default = false)
  • */
  • public function __construct($bContext = false) {
  • self::$bContext = $bContext;
  • set_error_handler(array ($this, 'errorHandler'));
  • }
  • /**
  • * @desc error handler
  • *
  • * @param constant $cErrno
  • * @param string $sErrStr
  • * @param string $sErrFile
  • * @param int $iErrLine
  • * @param mixed $mVars
  • */
  • public function errorHandler ($cErrno, $sErrStr, $sErrFile, $iErrLine, $mVars) {
  • if(!isset(self::$aTrans[$cErrno])) {
  • throw new exceptionErrorNotHandledYet($cErrno, $sErrStr, $sErrFile, $iErrLine, $mVars, self::$bContext);
  • } else {
  • throw new self::$aTrans[$cErrno]($cErrno, $sErrStr, $sErrFile, $iErrLine, $mVars, self::$bContext);
  • }
  • }
  • }
  • ?>
<?php
/**
 * @package package.exceptions.errors
 * @author Johan Barbier <barbier_johan@hotmail.com>
 * @version 20071017
 * @desc package transforming all php errors into catchable exceptions
 *
 */

/**
 * @name exceptionErrorGeneric
 * @desc Generic exceptionError class. Overload Exception::__toString() method and Exception::__construct() method
 *
 */
abstract class exceptionErrorGeneric extends Exception {
	/**
	 * @desc Error type
	 *
	 * @var string
	 */
	protected $sType;
	
	/**
	 * @desc Error file
	 *
	 * @var string
	 */
	protected $sErrFile;
	
	/**
	 * @desc Error line
	 *
	 * @var int
	 */
	protected $iErrLine;
	
	/**
	 * @desc Error context
	 *
	 * @var mixed
	 */
	protected $mVars;
	
	/**
	 * @desc is context enabled or not
	 *
	 * @var boolean
	 */
	protected $bContext;
	
	/**
	 * @desc constructor
	 *
	 * @param constant $cErrno
	 * @param string $sErrStr
	 * @param string $sErrFile
	 * @param int $iErrLine
	 * @param mixed $mVars
	 * @param boolean $bContext
	 */
	public function __construct($cErrno, $sErrStr, $sErrFile, $iErrLine, $mVars, $bContext = false) {
		parent::__construct($sErrStr, $cErrno);
		$this->sErrFile = $sErrFile;
		$this->iErrLine = $iErrLine;
		$this->mVars = $mVars;
		$this->bContext = $bContext;
	}
	
	/**
	 * @desc Exception::__toString() overloading
	 *
	 * @return string
	 */
	public function __toString() {
		$sMsg = '<strong>'.$this->sType.'</strong><br />';
		$sMsg .= $this->getMessage().'['.$this->getCode().']<br />';
		$sMsg .= '<em>File</em> : '.$this->sErrFile.' on line '.$this->iErrLine.'<br />';
		$sMsg.= '<em>Trace</em> :<br />'.$this->getTraceAsString().'<br />';
		if(true === $this->bContext) {
			$sMsg.= '<em>Context</em> :<br />'.print_r($this->mVars, true);
		}
		return $sMsg;
	}
}

/**
 * @desc exceptionErrors for Fatal errors
 *
 */
class exceptionErrorError extends exceptionErrorGeneric {
	protected $sType = 'Fatal error';
}

/**
 * @desc exceptionErrors for Warnings
 *
 */
class exceptionErrorWarning extends exceptionErrorGeneric {
	protected $sType = 'Warning';
}

/**
 * @desc exceptionErrors for Parse errors
 *
 */
class exceptionErrorParseError extends exceptionErrorGeneric {
	protected $sType = 'Parse error';
}

/**
 * @desc exceptionErrors for Notice
 *
 */
class exceptionErrorNotice extends exceptionErrorGeneric {
	protected $sType = 'Notice';
}

/**
 * @desc exceptionErrors for Core errors
 *
 */
class exceptionErrorCoreError extends exceptionErrorGeneric {
	protected $sType = 'Core error';
}

/**
 * @desc exceptionErrors for Core warnings
 *
 */
class exceptionErrorCoreWarning extends exceptionErrorGeneric {
	protected $sType = 'Core warning';
}

/**
 * @desc exceptionErrors for Compile errors
 *
 */
class exceptionErrorCompileError extends exceptionErrorGeneric {
	protected $sType = 'Compile error';
}

/**
 * @desc exceptionErrors for Compile warnings
 *
 */
class exceptionErrorCompileWarning extends exceptionErrorGeneric {
	protected $sType = 'Compile warning';
}

/**
 * @desc exceptionErrors for User errors
 *
 */
class exceptionErrorUserError extends exceptionErrorGeneric {
	protected $sType = 'User error';
}

/**
 * @desc exceptionErrors for User warnings
 *
 */
class exceptionErrorUserWarning extends exceptionErrorGeneric {
	protected $sType = 'User warning';
}

/**
 * @desc exceptionErrors for User notices
 *
 */
class exceptionErrorUserNotice extends exceptionErrorGeneric {
	protected $sType = 'User notice';
}

/**
 * @desc exceptionErrors for Strict errors
 *
 */
class exceptionErrorStrictError extends exceptionErrorGeneric {
	protected $sType = 'Strict error';
}

/**
 * @desc exceptionErrors for not handled yet errors
 *
 */
class exceptionErrorNotHandledYet extends exceptionErrorGeneric {
	protected $sType = 'Not handled yet';
}

/**
 * @desc error handler, calling correct exceptionError type
 *
 */
class exceptionErrorHandler {
	/**
	 * @desc translation between context error and exceptionError type of class
	 *
	 * @var array
	 */
	public static $aTrans = array (
		E_ERROR => 'exceptionErrorError',
		E_WARNING => 'exceptionErrorWarning',
		E_PARSE => 'exceptionErrorParseError',
		E_NOTICE => 'exceptionErrorNotice',
		E_CORE_ERROR => 'exceptionErrorCoreError',
		E_CORE_WARNING => 'exceptionErrorCoreWarning',
		E_COMPILE_ERROR => 'exceptionErrorCompileError',
		E_COMPILE_WARNING => 'exceptionErrorCompileWarning',
		E_USER_ERROR => 'exceptionErrorUserError',
		E_USER_WARNING => 'exceptionErrorUserWarning',
		E_USER_NOTICE => 'exceptionErrorUserNotice',
		E_STRICT => 'exceptionErrorStrictError'
	);
	
	/**
	 * @desc is context enabled or not
	 *
	 * @var boolean
	 */
	public static $bContext = false;
	
	/**
	 * @desc constructor, optional bContext boolean can be given if you want context to be displayed or not
	 *
	 * @param boolean $bContext (optional, default = false)
	 */
	public function __construct($bContext = false) {
		self::$bContext = $bContext;
		set_error_handler(array ($this, 'errorHandler'));
	}

	/**
	 * @desc error handler
	 *
	 * @param constant $cErrno
	 * @param string $sErrStr
	 * @param string $sErrFile
	 * @param int $iErrLine
	 * @param mixed $mVars
	 */
	public function errorHandler ($cErrno, $sErrStr, $sErrFile, $iErrLine, $mVars) {
		if(!isset(self::$aTrans[$cErrno])) {
			throw new exceptionErrorNotHandledYet($cErrno, $sErrStr, $sErrFile, $iErrLine, $mVars, self::$bContext);
		} else {
			throw new self::$aTrans[$cErrno]($cErrno, $sErrStr, $sErrFile, $iErrLine, $mVars, self::$bContext);
		}
	}
}
?>

 Conclusion

A noter que seules les erreurs gérées par set_error_handler() ne sont interceptées, et donc les suivantes ne peuvent m'être :
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING

Juste pour dire parce que c'est toujours agréable : ce code a terminé 2ème des Innovation Awards de Novembre 2007 de phpclasses.org :-)

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Historique

18 octobre 2007 12:52:13 :
Petite modif pour prendre en compte les erreurs non encore gérées par ce package (sait-on jamais...), et pour pouvoir appeler la méthode de manière statique.
25 octobre 2007 23:29:10 :
Ajout d'une précision suite à la remarque de Celeg
01 janvier 2008 10:15:34 :
RAS

 Sources du même auteur

Source avec Zip ASTUCES/HACK PHP
SQUELETTE DE GESTION DES DROITS
[PHP 5.1] CLASS STRING : NOUVEL EXEMPLE SUR LA SPL
Source avec Zip Source avec une capture [PHP 5.1] PHOTOPHOP (PHPDRAW 2)
Source avec Zip Source avec une capture [PHP5.1] O-LOC : CLASSE ET BACKOFFICE D'INTERNATIONALISATION

 Sources de la même categorie

CALCUL D'UNE DISTANCE ORTHONORMIQUE par bossfoot
Source avec Zip ESPACE ADMIN SIMPLE par mousaid_88
Source avec Zip IMAGINE-CMS V2.20 par djack69
Source avec Zip AFFICHAGE ET GESTION DE DIAPORAMA EN PHP SANS BASE DE DONNÉE... par mldvb
Source avec Zip Source avec une capture PARSER ALLOCINE par cyrhades

 Sources en rapport avec celle ci

Source avec Zip Source avec une capture GESTIONNAIRE DE FICHIERS | MYSQL PHP 5.X {NEMENTON PHP MANA... par Nementon
TRAITER LES ERREURS PHP GRAVES, NON INTERCEPTABLES par FredT
PHP 5 CLASSES DE REDIRECTION DES EXCEPTIONS DANS UN SYSTÈME... par guill76
CLASSE DE CONFIGURATION POUR LA GESTION D'ERREUR par FredT
Source avec Zip [PHP5] GESTIONNAIRE DE CONFIGURATIONS par neigedhiver

Commentaires et avis

Commentaire de Teclis01 le 17/10/2007 21:29:05

Un code propre est élégant (à mon goût) avec cet exemple concret d'utilisation des tutos... Y'a pas a dire il nous gâte!
Si personne se met au pattern design avec ça !

Commentaire de coucou747 le 18/10/2007 07:07:22 10/10

c'est beau et c'est super utile, rien a redire ici

Commentaire de malalam le 18/10/2007 12:54:11 administrateur CS

@Teclis => merci :-)

@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 :-)

Commentaire de guill76 le 18/10/2007 20:07:18 10/10

Ouais très bon boulot, pas testé, mais content de retrouver des codes de qualité et utilité (Je crois que t'as pensé à tout dans ces classes)
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!!    

Commentaire de Calak le 20/10/2007 18:10:11

Yep, tu m'en parlais justement ^^
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

Commentaire de celeg le 22/10/2007 23:36:21 4/10

j ai essaye ca dans le try test(), mais l'erreur n est pas capture. Donc ta class recupere les erreurs fatale ou seulement les erreurs utilisateurs?

Commentaire de malalam le 23/10/2007 00:38:23 administrateur CS

Les erreurs fatales ne peuvent pas être capturées...set_error_handler ne capture que les warning, notice, et toutes les erreurs utilisateurs.
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 :-)

Commentaire de audayls le 23/10/2007 20:36:50 10/10

@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 -_-"

Super code made by Boss Malalam, à utiliser impérativement XD

Commentaire de coucou747 le 23/10/2007 21:18:38

celeg, en effet, je suis d'accord, ce code est pourri, il ne permet meme pas de catcher une parse error sur  la fonction d'autoload....

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...

Commentaire de malalam le 24/10/2007 19:54:54 administrateur CS

Merci pour le soutien en tous cas :-)

Commentaire de coucou747 le 24/10/2007 20:01:28

malalam, peux-tu supprimer un 4/10 ici et supprimer quelques 10/10 sur des sources mals codes ? histoire de donner un sens aux notes ?

Commentaire de malalam le 24/10/2007 20:24:17 administrateur CS

Non, on ne peut plus depuis que les commentaires sont obligatoires pour pouvoir noter. Ce n'est pas un mal d'ailleurs :-)

Commentaire de celeg le 25/10/2007 08:29:41

" quand je tape un poeme et non mon code, php ne marche plus !"
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.

Commentaire de malalam le 25/10/2007 09:36:09 administrateur CS

@Celeg => désolé, je ne suis pas magicien. Ce qui peut-être modifié en PHP, je peux le faire. Ce qui nécessite de toucher au moteur de PHP, en php, je ne peux pas le faire. Utiliser cette source implique de connaître les limitations de PHP, aussi n'ai-je pas crû bon de préciser l'évidence. Peut-être devrais-je ajouter : attention, ce code est écrit en php5, ce qui implique qu'il ne fonctionnera pas en php4, ni en php3? Qu'il ne se compile pas non plus sous Visual Studio, et ne fonctionne pas en local si vous n'avez pas un serveur local avec l'interpréteur PHP installé...?

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...?

Commentaire de celeg le 25/10/2007 11:14:04

Encore une fois, je repette tu marque "TRANSFORMER TOUTES LES ERREURS PHP EN EXCEPTIONS INTERCEPTABLES" pour une personne qui ne connais pas trop le comportement oui, il y aura confusion, pour toi pas je n'en doute pas. J aurais marqué "capture les erreurs utilisateurs php".
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.

Commentaire de Calak le 25/10/2007 15:56:19

Au fait, je n'avais pas noté, et je ne le fais pas tout de suite.
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

Commentaire de audayls le 25/10/2007 21:34:02

@Celeg :
"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 ;-)

Commentaire de coucou747 le 25/10/2007 22:13:48

"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."
=>
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...

Commentaire de malalam le 25/10/2007 22:48:36 administrateur CS

@Celeg =>  E_COMPILE_WARNING n'est pas signalé par un warning. Donc pour moi, un warning, c'est le E_WARNING. A vrai dire, la plupart d'entre nous ne verrons sans doute jamais ce type d'erreurs. Cette classe ne capture pas que les erreurs utilisateur. les erreurs utilisateur sont les E_USER_*.
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... ;-)

Commentaire de malalam le 25/10/2007 23:13:55 administrateur CS

@Celeg && @Calak => juste une précision parce que ça me paraissait évident mais...ça ne l'est peut-être pas tant que ça : si j'ai scindé autant mes classes, je vous l'ai dit, c'est pour pouvoir les traiter chacune à part. J'ai eu l'air de dire "pour les modifier, ajouter des traotements spécifiques etc". Oui, mais heu, on peut déjà les traiter à part en l'état, justement? Vous n'êtes pas sans ignorer comment on intercepte des exceptions :
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).

Commentaire de malalam le 25/10/2007 23:30:46 administrateur CS

@Celeg => par contre je tiens compte de ta remarque : je précise les erreurs NON gérées par celle classe (à savoir celles non gérées par set_error_handler). Ainsi, pas de surprise.

Commentaire de Calak le 26/10/2007 16:24:30

Tu aurais pu (et c'est du basique, qui reste dans le contexte même du noyau de base d'un ExceptionHandler ) mettre un set_exception_handler, pour catcher les exceptions non attrapée.
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:
<code>
try {
    // Some code here
}
catch ( Exception $e ) {
  switch ( $e->getCode() ) {
    case E_USER_WARNING:
      //...
    break;

    case E_USER_ERROR:
      //...
    break;
    //....
  }
}
</code>
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 ^^

Commentaire de malalam le 26/10/2007 20:33:51 administrateur CS

Hello,

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.

Commentaire de malalam le 01/12/2007 11:35:08 administrateur CS

Hey dudes,

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 !!

Commentaire de FredT le 02/01/2008 11:13:53 9/10

Salut,
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.


Commentaire de malalam le 02/01/2008 14:13:37 administrateur CS

Tu sais, les classes internes de php la,cent aussi pour beaucoup des exceptions. Si le codeur oublie ses try catch...on ne peut pas faire grand chose pour lui.
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.

Commentaire de gr43 le 06/03/2009 03:23:47

Bonjour, j'espère que certains qui ont participé à ce topic lirons ce message.
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

Commentaire de malalam le 06/03/2009 19:11:30 administrateur CS

Tien, un mort déterré...
@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.

Commentaire de malalam le 06/03/2009 19:44:13 administrateur CS

Ah...je me dis d'un coup : suis pas sympa, et si ça se trouve, je l'adresse à un...comment as-tu dit...ah oui! à un "pro". Donc si tu es parvenu, en php, avec un set_error_handler(), à intercepter une erreur fatale non "recoverable", je m'incline...et je veux évidemment voir ton code afin de le donner à tous les dév de mon équipe!
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).

Commentaire de malalam le 06/03/2009 19:45:06 administrateur CS

Ouais je sais :"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".
Ouais. Tout à fait d'accord avec toi. Et toi...?

Commentaire de coucou747 le 06/03/2009 20:05:54

Ook c'est simple, whitespace c'est dur


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.

Commentaire de gr43 le 09/03/2009 10:33:06

Je ne me considère pas meilleur que vous ou que n'importe qui d'ailleurs, mais trouve moi un seul de mes commentaires où j'ai eu réaction si méprisante que la votre. (c'est vous que je compare à des pros et non moi, je pourrais réécrire mon message s'il n'était pas clair). Mais c'est une affaire de gout, puisque je pense que vous vous n'êtes pas trouvé arrogant. Dans ce cas, une relecture des 1er post de cette page s'impose.

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

Commentaire de gr43 le 09/03/2009 10:43:53

Oui pour le design pattern, c'est pas toi qui en avais parlé mais Teclis01 et ce n'était pas une remarque mais plus une interrogation. Je ne suis pas bien d'accord et ni avec l'idée d'un design pattern strategy. Si je ne me trompe, je ne suis pas une star des DP entre autre d'ailleurs, mais dans un strategy un lien a-un est préférable à un lien est-un (on encapsule un comportement pouvant évoluer).

Commentaire de malalam le 09/03/2009 19:11:14 administrateur CS

@GR43 : tout d'abord, je ne me rappelle pas avoir agressé qui que ce soit en premier. Maintenant, si toi tu trouves que c'est le cas, bah...je n'ai rien à y redire. C'est ton sentiment, tant pis. Je réagis juste à une sanction basée sur une méconnaissance du fonctionnement d'un langage. J'explique le pourquoi...et je réagis à la sanction avant explications du pourquoi. Je n'ai rien contre quelqu'un qui n'aime pas un code (je suis admin ici...je fonctionne de la même manière pour tous les codes : une sanction non justifiée est...injuste : il faut d'abord comprendre un code et ses implications pour le juger, il me semble; à l'école, aurais-tu accepté d'être noté par un prof qui ne connait rien au sujet (ou à la matière) sur lequel (laquelle...) tu as fait un devoir ? Sans qu'il ait cherché à se renseigner ? genre un prof de littérature qui note un devoir de math. Il me semble que c'est un comportement curieux).

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.


Commentaire de gr43 le 10/03/2009 09:53:18

Les remarques que j'ai émises ne te concernaient pas seulement et les commentaires que j'ai repris dans mon premier message ne me semblaient pas très sympa (c'est vrai que le tien n'était pas le pire). Je ne vais pas les réécrire et je ne reviendrais plus non plus le sujet. J'avais seulement envie de pousser une gueulante car c'est souvent que des commentaires sont plus proches de la méchanceté que de la critique (ici je ne vise personne en particulier). Je ne remet pas non plus en doute vos connaissances car vous avez aidé beaucoup de monde et moi en particulier.
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.

Commentaire de FredT le 10/03/2009 10:12:12

Hello...
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...

Commentaire de gr43 le 10/03/2009 11:40:11

Salut, méthode originale et astucieuse. J'essaierai également de regarder. Avec 'ErrorDocument 500 ./ err500.php' error_prepend_string et error_append_string ne sont pas utile, si? et display_error=on, non plus?.
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()

Commentaire de malalam le 10/03/2009 19:21:11 administrateur CS

En effet, concernant les commentaires sur php.net, je regardais les derniers...de la page, pas dans le temps, mea culpa, c'était stupide :-) : register_shutdown_function est une fonction très utile, mais elle ne permet en effet pas de gérer efficacement les erreurs : elle gère l'arrêt d'un script. D'expérience, elle n'est pas non plus très pratique à porter (ça dépend beaucoup du serveur, et sans doute aussi du navigateur je suppose). Mais surtout, on ne peut que logger l'erreur (qui l'est dans le log d'erreur php habituel de toute manière), pas facilement (on peut toujours faire quelque chose, mais ça implique des codes très complexes, tordus et peu fiables : on ne sait pas ce que l'erreur a pu provoquer comme instabilité, et il est difficile de savoir ce qui a généré l'erreur de manière dynamique) influencer sur le comportement du script suite à l'erreur, puisque de toute manière, le script s'arrête (contrairement à un bloc try catch).
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.

Commentaire de Neo_Ryu le 24/02/2010 23:05:09 10/10

Très bonnes classe qui me sera utile, je regrette d'ailleurs de ne pas voir plus souvent du code source aussi propre !

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... ^^

Commentaire de malalam le 25/02/2010 19:57:35 administrateur CS

Merci :-) Ca commence à dater cette classe...mais je l'utilise tjrs professionnellement mine de rien.
Faudrait que je re-poste un peu...ça fait un bail (manque de temps :-().

Commentaire de coucou747 le 25/02/2010 22:37:03

tu manques ici.

Perso, j'ai abandonne le php et j'ai plus tellement le droit de bosser pour le web en open.

Commentaire de Neo_Ryu le 01/03/2010 16:00:49

Le manque de temps est souvent le lot commun à tout les développeurs ^^

Commentaire de malalam le 02/03/2010 10:38:28 administrateur CS

Malheureusement, je n'arrête pas de travailler en ce moment, le soir, le week-end...ça dure et ça n'a pas l'air de vouloir se calmer.
Mais l'envie est là!
Je vais essayer de repasser un peu plus souvent...
Ravi d'avoir de tes nouvelles ceci dit, Max :-)

 Ajouter un commentaire


Discussions en rapport avec ce code source dans le forum

Handler d'une table [ par apz ] salut, que veut dire le message d'erreur suivant : Citation: Reçu l'erreur 127 du handler de la table Merci Handler de la table [ par apz ] salut, que veut dire le message d'erreur suivant : Citation: Reçu l'erreur 127 du handler de la table Merci Problème syntaxique sous PHP [ par olive59 ] Débutant sous PHP et ayant tendance à mélanger les différents langages que j'ai essayé d'assimiler, quelqu'un pourrait-il me renseigner sur le problèm :::::: URGENT !!! ENVOI D'IMAGE PAR FTP !!!! ERREUR :::::: [ par kkz_mil3k ] j'essaie d'nevoyer un fichier image gif ou jpg sur un ftp via ce formulaire php :------------------------------------------- //**connecte au ftp sc Message ERREUR Suite tentative de transfert d'un fichier [ par David ] Il en résulte le message d'erreur suivant : Warning: Unable to create '../occas/1.jpg': Permission denied in /home4/eq9846/html/test/prive/admin/edi_o Astuce du jour #1: Comment configurer une erreur de la base de donné MySql [ par SmallToad ] Quand vous avez de des erreurs de la base de donnée, êtes-vous déjà demander comment configurer le message d'erreur de la base de donnée MySql C'est aidez moi!!! [ par mic29 ] Voila je débute dans le milieu et je viens de faire mon forum.J'ai une erreur mais je ne voie trop comment y remédier.A chaque fois que je poste un me aidez moi!!! [ par mic29 ] Voila je débute dans le milieu et je viens de faire mon forum.J'ai une erreur mais je ne voie trop comment y remédier.A chaque fois que je poste un me PROBLEME SIMPLE [ par g0belin ] sa me repond sa---------------------------ERREUR--------------------Réponse serveur SQL : You have an error in your SQL syntax near '@msn.com, 1234567 pb avec ma base [ par Xime ] salut :)j'essaye de me connecter a ma base oracle en faisant un truc tout con mais g un probleme et je ne voi pas ou !voila ce ke je fais : &lt;?php$c


Nos sponsors


Appels d'offres

Sondage...

Comparez les prix

CalendriCode

Mars 2010
LMMJVSD
1234567
891011121314
15161718192021
22232425262728
293031    

Consulter la suite du CalendriCode

 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,858 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales