begin process at 2008 08 20 14:51:35
1 228 895 membres
260 nouveaux aujourd'hui
14 259 membres club

Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum.
Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

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


Information sur la source

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é: 4 434 / 173

Note :
8,6 / 10 - par 5 personnes
8,60 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

Commentaire sur cette source (26)
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 :-)
Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip

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
  • signaler à un administrateur
    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 !

  • signaler à un administrateur
    Commentaire de coucou747 le 18/10/2007 07:07:22 10/10

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

  • signaler à un administrateur
    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 :-)

  • signaler à un administrateur
    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!!    

  • signaler à un administrateur
    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

  • signaler à un administrateur
    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?

  • signaler à un administrateur
    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 :-)

  • signaler à un administrateur
    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

  • signaler à un administrateur
    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...

  • signaler à un administrateur
    Commentaire de malalam le 24/10/2007 19:54:54 administrateur CS

    Merci pour le soutien en tous cas :-)

  • signaler à un administrateur
    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 ?

  • signaler à un administrateur
    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 :-)

  • signaler à un administrateur
    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.

  • signaler à un administrateur
    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...?

  • signaler à un administrateur
    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.

  • signaler à un administrateur
    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

  • signaler à un administrateur
    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 ;-)

  • signaler à un administrateur
    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...

  • signaler à un administrateur
    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... ;-)

  • signaler à un administrateur
    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).

  • signaler à un administrateur
    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.

  • signaler à un administrateur
    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 ^^

  • signaler à un administrateur
    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.

  • signaler à un administrateur
    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 !!

  • signaler à un administrateur
    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.


  • signaler à un administrateur
    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.

Ajouter un commentaire

Pub



Appels d'offres

CalendriCode

Août 2008
LMMJVSD
    123
45678910
11121314151617
18192021222324
25262728293031

VS Express FR Gratuit !

VS Express en français et 100% gratuit !

Téléchargements

Logiciels à télécharger sur le même thème :

Boutique

Boutique de goodies CodeS-SourceS