Bonjour,
Je suis préoccupé par une question de principe. En effet, un ami m'a fait remarquer un jour qu'en POO toute méthode devait pouvoir être détruite par son constructeur.

Or, j'utilise comme 90% des programmeurs, je pense, la fonction die() à foison.

Comment faire pour gérer les erreurs ? (je précise que je n'ai pas plus confiance que ça dans la gestion des erreurs de php5.

D'avance merci

En effet, un ami m'a fait remarquer un jour qu'en POO toute méthode devait pouvoir être détruite par son constructeur.

Je ne comprends pas ce que tu veux dire ici...
Une methode n'a pas de constructeur... seuls les objets en ont.
Un constructeur ne dedruit rien habituellement...

Or, j'utilise comme 90% des programmeurs, je pense, la fonction die() à foison.

En fait, tout depend de comment et quand tu l'utilises. IMHO, tu peux utiliser des die pour debugger... mais par la suite, ca ne fait pas du tout credible si un utilisateur arrive sur une page blanche...

En effet, un ami m'a fait remarquer un jour qu'en POO toute méthode devait pouvoir être détruite par son constructeur.

il devait parlé d'objet et non de methode, en php5 tu peut avoir un constructeur et un destructeur par objet

Comment faire pour gérer les erreurs ? (je précise que je n'ai pas plus confiance que ça dans la gestion des erreurs de php5.

pourquoi le mecanisme des exceptions fonctionne tres bien.

mais surtout comment utilise tu les die???

La gestion des erreurs en php5 est excellente, elle fait gagner énormément de code, dans la classe elle même ainsi que dans l'instanciation.

Très sincèrement, passer à côté d'une fonctionnalité aussi simple et aussi efficace lors que l'on a les moyens de l'utiliser tient de la bêtise (et j'suis gentil).

M'enfin pour c'que j'en dis ...

Bonjour,
Je suis préoccupé par une question de principe. En effet, un ami m'a fait remarquer un jour qu'en POO toute méthode devait pouvoir être détruite par son constructeur.

Or, j'utilise comme 90% des programmeurs, je pense, la fonction die() à foison.

Comment faire pour gérer les erreurs ? (je précise que je n'ai pas plus confiance que ça dans la gestion des erreurs de php5.

D'avance merci

Ton ami a raison, une méthode ne devrait pas arrêter le système quand une erreur occure, elle doit gérer l'erreur en retournant un code-erreur à l'appelant.

L'utilisation de die est donc non conseillé dans un objet d'autant plus qu'elle ne fait qu'afficher un message tout en arrêtant le procéssus à mort.
le die ne detruit pas seulement la thread de la méthode mais aussi l'objet conteneur et les programmes appelant.

L'idéal en programmation objet est de s'aligner au niveau de l'objet à programmer pour concevoir le comportement de ses méthodes vis-à-vis des exceptions qui devraient provoquer ou pas son arrêt.

Le capteur d'exception try .... catch () est dans ce cas plus intéréssant que les die et exit

En principe l'algorithme de gestion des exceptions dans une méthodes qui manipule des commandes génératrices d'erreurs est le suivant :

class foo {
    function foo (args) {
       //travailler tout en observant une erreur
       try {
            //le travail à faire
       }
      catch (MyException $e) { 
           //capteur de try : reçoit l'objet erreur et le nomme '$e'
          //programmer ce que vous devez faire de l'erreur $e
          //Peut être  retourner l'objet $e à l'appelant :
          return $e;
          //Peut être retourner un False pour signaler un echec de la méthode
           return false;
          //Peut être afficher l'erreur survenue: (déconseillé)
            echo $e->getError(); 
        }
}

Merci de vos réponses.
Pour la formulation j'avoue ne pas avoir été très précis.

j'allais opté pour une gestion simple des erreurs (un return false) qui retourne une erreur bateau (type "l'envoi de ce message est un échec"), avec une inscription dans un log.txt ; mais vous avez l'air très enthousiates avec la gestion des erreurs de php.

Ce que je lui reproche principalement est sa documentation. J'aimerais avoir un exemple plus développé que l'officiel (oui, j'avoue ne pas être un programmeur né ).

Auriez-vous un lien ?

D'avance merci.

Je viens de passer quelques temps à approfondir la gestion des exceptions.

Effectivement, c'est intéressant pour les erreurs au sens propre.

Cependant ma question touchait aussi à la gestion des erreurs dans mon processus ; ou en d'autres terme, si je prends l'exemple de l'identification éviter qque chose du type
Même si j'enrobe le message d'un en-tête et d'un pied.

Je doute qu'il soit opportun de lancer une exception pour cela.

Votre avis ?

$resultat=mysql_fetch_array($requete);
if($resultat!=1)
die("Vous n'êtes pas enregistré");

est ce que tu pense que ce fonctionnement parait normal ,pour ton appli?
pour ma part non, à la place du die je ferai une redirection sur la page de login et j'afficherai le message.

Maintenant comment utiliser les exceptions a bon escient j'aimerai connaitre l'avis des autres developpeur. je declenche une exception pour une clé de configuration non trouvé, par exemple.

$resultat=mysql_fetch_array($requete);
if($resultat!=1)
die("Vous n'êtes pas enregistré");

est ce que tu pense que ce fonctionnement parait normal ,pour ton appli?
pour ma part non, à la place du die je ferai une redirection sur la page de login et j'afficherai le message.

Maintenant comment utiliser les exceptions a bon escient j'aimerai connaitre l'avis des autres developpeur. je declenche une exception pour une clé de configuration non trouvé, par exemple.

Pour Sertt:
Je suis d'accord avec Jeff, ton exemple n'est même pas une exception (erreur) : le fait qu'un client ne soit pas enregistré fait partie de la gestion de l'authentification (reconnaissance de l'identité) des clients.

Les exceptions sont les erreurs prévisibles succeptibles d'entraver le bon fonctionnement d'une méthode.
Ces erreurs sont souvent dues aux problèmes de calculs, d'opérations d'entrée/sortie (accès aux périphériques) ou liées au dysfonctionnement du système

Penser à toutes les erreurs possibles n'est pas une tâche aisée, mais surmontable par le biais des capteurs d'erreurs.
Programmer les alternatives en cas d'erreurs relève de la décision du développeur et c'est cas par cas.

Pour Jeff: Si tu veux dire par clé de configuration, un paramètre nécéssaire au bon fonctionnement de l'application, certe c'est une exception qu'il faudra gérer le plus intélligement possible :
- Si la clé de configuration peut être regénérée automatiquement pourquoi ne pas programmer de le faire en cas d'exception
- Si ce n'est pas possible de régler le problème automatiquement, l'alternative qui gère l'exception ne peut, selon le dégré de gravité de l'exception, que veuiller à terminer l'application en limitant les dégats

Généralement, pour les erreurs rattrapables comme lorsqu'une application a besoin d'accèder à un périphérique qui n'est pas prêt (comme la disquette, un lecteur réseau non dispo, un dossier manquant ou tout simplement par manque de droit d'accès) corriger l'exception consiste donc à :

• Si l'on ne peut programmer la correction automatiquement :
  - Avertir l'utilisateur en lui expliquant le problème
  - Eventuellement demander son intervention pour tenter d'arranger les choses
  - Et dans le pire des cas, si le problème persiste prévoir une échapatoire
  qui arrête le procéssus correctement en sauvegardant les données

Je viens de passer quelques temps à approfondir la gestion des exceptions.

Effectivement, c'est intéressant pour les erreurs au sens propre.

Cependant ma question touchait aussi à la gestion des erreurs dans mon processus ; ou en d'autres terme, si je prends l'exemple de l'identification éviter qque chose du type

Code : Tout sélectionner

$resultat=mysql_fetch_array($requete); if($resultat!=1) die("Vous n'êtes pas enregistré");

Même si j'enrobe le message d'un en-tête et d'un pied.

Je doute qu'il soit opportun de lancer une exception pour cela.

Votre avis ?

Bonjour,

j'ai écrit un article chez un site d'aide en php sur la gestion des exceptions, il y a quelques temps. ça doit être le premier résultat de cette page :

http://www.google.fr/search?hl=fr&q=exc ... DcountryFR

bon courage.

est ce que tu pense que ce fonctionnement parait normal ,pour ton appli?
pour ma part non, à la place du die je ferai une redirection sur la page de login et j'afficherai le message.

Cela n'est pas possible. En effet, dans un exemple plus compliqué où la méthode est appelée en milieu de page (càd : les header ont déjà été envoyés), je retrouve mon problème !

Donc si je résume, pour vous, l'utilisation des throw/try-catch se restreint à la gestion des erreurs fatales ? D'ailleurs, j'ai du mal à faire la différence entre un exception et une erreur. Où est la limite pour vous ?

NB : Je venais de découvrir le site de mcorgnet. si je ne me trompe pas, à la question que je posais précédemment (remplacer die("Vous n'êtes pas enregistré")) il répond
où
non ?

D'avance merci

L'intérêt des exceptions résident aussi de factoriser la gestion des erreurs. Au lieu de faire sans cesse des try / catch dans des méthodes, tu peux "lever" des exceptions (faire un throw new Exception()).

Ainsi, le point d'entrée de ton programme fait un try / catch. Tu récupères donc toutes les exceptions levées et tu peux donc agir en conséquence : logguer, afficher une page d'erreur, retenter le traitement...

La gestion des exceptions prend tout son sens quand tu définis des exceptions "classiques" : erreur de type attendu ds des méthodes, variable null..., un peu comme en Java. ALors il devient très aisée de debugguer.

PS : un gestionnaire d'exception sympathique : http://www.sitepoint.com/blogs/2006/04/ ... ue-screen/