[POO] Utilisation des exceptions

Bonsoir,

Je me pose des questions sur l'utilisation des exceptions, j'aimerais bien ne pas les détourner... car "c'est le mal"... donc voici un petit exemple pour illustrer ma question :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

<?php   class Chat {   private $nom;   public function __construct($nom = '') {   try { if(strlen(trim($nom)) != 0) $this->nom = $nom; else throw new Exception('Vous devez donner un nom au chat !'); } catch(Exception $e) { echo $e->getMessage(); } }   public function miaou() {   echo 'miaou'; } }   $monChat = new Chat(); echo '<hr />'; $monChat->miaou();   ?>

---

Lors de l'exécution de ce code, une exception est levée, car je n'ai pas donné de nom au chat... donc le code "s'arrête" dans le bloc try puisque le catch a capturé l'exception qui a été lancée... Ok.
MAIS, j'aimerais que si une exception est levée, alors l'objet devienne inutilisable en d'autres termes, le chat ne devrait pas faire miaou...
J'ai tenté dans ma class d'exception (qui étend la class Exception de PHP) d'arrêter le "truc", en mettant un bête die; évidemment çà arrête tout... mais je voudrais simplement "arrêter" mon objet, et faire en sorte que le reste de la page s'affiche.

Est-ce une bonne idée ? Ou une très mauvaise ?

Salut,

C'est plus un souci de conception: ne mets pas de catch dans ton constructeur, et alors c'est au code d'instantiation de traiter l'erreur:

Code:

---

1 2 3 4 5 6 7 8 9

try { $monChat = new Chat(); echo '<hr />'; $monChat->miaou(); } catch(Exception $e) { echo $e->getMessage(); }

---

ERE

Salut,

Oui de conception ! J'ai vainement cherché un sous-forum "conception" et c'est bien dommage qu'il n'y en ait pas, c'est important ! :D

Ahhh, c'est pas bête... ceci dit cela implique de "bien instancier"... et donc finalement de gérer les exceptions en dehors de la class... ce qui ne m'arrange pas. Car je souhaite que ma class soit automome, qu'elle se gère toute seule comme une grande.

Donc si je reprends ma question initiale, à savoir est-ce bien ou mal ? Toi tu n'y vois pas d'inconvénient, çà ne serait pas "mal se servir des exceptions".
Si qq'un d'autre veux faire partager son opinion, je suis preneuse.

Pour le reste je vais donc tâcher de garder mes try catch au sein de ma class, et donc de faire en sorte que mes exceptions soient fatales à l'objet.

Merci de ton aide ERE

Salut,

Tu écrivais dans ton premier post:

Citation:

---

MAIS, j'aimerais que si une exception est levée, alors l'objet devienne inutilisable en d'autres termes, le chat ne devrait pas faire miaou...

---

Si la class devient inutilisable, l'appelant doit le savoir et c'est à lui de prendre une décision. Quel intérêt pour ta class de gérer l'erreur ? Car là est à mon avis une erreur de conception: ce n'est pas à ta class de gérer l'erreur de l'appelant; si celui-ci ne fournit pas de nom c'est qu'il ne respecte pas la class Chat, et il est donc normal qu'il prenne une erreur en retour. C'est de la responsabilité du développeur de se conformer à l'utilisation de la class telle que son concepteur l'a pensée. Si le concepteur d'une class doit gérer les erreurs des utilisateurs, on n'en finit jamais...

2 façons de "générer" cette erreur:

1. En ne spécifiant pas de valeur par défaut dans le constructeur:
   Code:

   ---

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

   <?php class Chat { private $nom;   public function __construct($nom) { $this->nom = $nom; } public function miaou() { if (empty($this->nom)) throw new Exception("Le chat n'est pas encore né ! "); echo 'miaou'; } }   $monChat= null; try { $monChat = new Chat(); echo '<hr />'; $monChat->miaou(); } catch(Exception $e) { echo $e->getMessage(); } ?>

   ---

   Ainsi
   Code:

   ---

   $monChat = new Chat();

   ---

   génère au moins un warning PHP mais pas une erreur :? , par contre tu peux la générer lors de l'appel à miaou...
2. En gérant le nom avec une valeur par défaut:
   Code:

   ---

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

   <?php class Chat { private $nom='';   public function __construct($nom='') { if(strlen(trim($nom)) != 0) $this->nom = $nom; else throw new Exception('Vous devez donner un nom au chat !'); } public function miaou() { echo 'miaou'; } }   try { $monChat = new Chat(); echo '<hr />'; $monChat->miaou(); } catch(Exception $e) { echo $e->getMessage(); } ?>

   ---

   A noter que l'exception généré dans le constructeur interdit l'instanciation de la class, donc $monChat->miaou(); ne pourra jamais être appelé

ERE

"Quel intérêt pour ta class de gérer l'erreur ? Car là est à mon avis une erreur de conception: ce n'est pas à ta class de gérer l'erreur de l'appelant; si celui-ci ne fournit pas de nom c'est qu'il ne respecte pas la class Chat, et il est donc normal qu'il prenne une erreur en retour."

Oui je suis d'accord... dans le cas du chat ; La class que je suis en train de faire est un poil plus compliquée, et il se pourrait que l'instanciation de la class, et/ou l'appel aux méthodes de la class se fasse de manière dynamique ; plus clairement dit : les paramètres passées aux méthodes, proviendraient d'un système d'information dont j'ignore tout. Et qui peut donc être truffé "d'erreurs" (ne me demande pas lesquelles).

Et c'est là que se pose le problème, comment ne pas ruiner tout l'affichage du site qui utilise cette class, lorsque celle-ci est mal exploitée... par une base (et en évitant au développeur de lui faire ce travail de mise en place d'exception, ce qui de mon avis... n'est pas de son ressort... mais je débute l'objet et ma conception des choses est peut être très moyenne) ! L'instanciation faite par le développeur peut être nickel... mais si derrière on a une base complètement moisie... :aie:

Est-ce que je me suis pris la tête trop fort, ou bien est-ce une réflexion justifiée ?

Re,

Si en entrée tu as des données que tu ne maitrises pas, il me semble encore plus justifié de traiter les erreurs. Que ce soit le rôle du développeur ne me choque pas, il faut bien que quelqu'un s'en occupe... et ne pas le faire n'engendre que le report des problèmes. C'est ce que j'appelle habituellement familièrement le "théorème de conservation des emmerdements". ;)

ERE

J'ai laissé mijoter tout ce que je tu m'as dit et effectivement je commence à changer mon point de vue.

Je vais donc laisser les vannes ouvertes afin de ne pas accumuler les emmerdements. :D

Donc à charge du développeur d'instancier un objet au sein d'un bloc try si il ne veut pas amocher sa page.

Merci beaucoup pour tes éclairages.

Re,

Pour finir, c'est exactement ce que tu précises:

Citation:

---

Donc à charge du développeur d'instancier un objet au sein d'un bloc try si il ne veut pas amocher sa page.

---

C'est SA page, à lui de prendre ses responsabilités; de ton côté tu fournis une class irréprochable.

ERE

Irréprochable, irréprochable... ne nous emballons pas tout de même :aie:

Citation:

---

Envoyé par Huntress

Irréprochable, irréprochable... ne nous emballons pas tout de même :aie:

---

Il fallait comprendre "tu dois fournir une class irréprochable." :mouarf:

ERE

Levée de l'exception dans la classe , interception dans l'appel.
En revanche c'est dommage que l'on ai pas le droit a un petit warning en php quand on instancie une classe suceptible de levée une exception sans la placer dans un bloc try/catch , un peu comme en java.

Ah donc toi (grunk) tu fais des thrown à tout va dans ta class, et tu fais ton new et tes appels de méthode de class au sein d'un try avec plein de catch ?

Pas du tout de try catch dans ta class ?

Tout dépend. Une exception n'est jamais qu'un commutateur particulier. Une classe peut très bien gérer certaines exceptions qui lui sont propres tout en déléguant une autre partie qui est à gérer par la procédure.

Même si on assimile souvent une exception à une erreur gérable, on peut les exploiter de manière beaucoup plus variée.

Ahhh en fait il s'agit plus de mon optique surtout aujourd'hui, puisque j'ai admis l'utilisation des try catch en dehors de la class (merci emmanuel.remy)... et oui après "tant" d'années en procédural il est difficile d'appréhender certains aspects de la POO.

Merci à vous 3 pour avoir partagé votre vision des choses, si il y a encore une âme généreuse qui tient à partager... :ccool:

Citation:

---

Envoyé par Petibidon

Tout dépend. Une exception n'est jamais qu'un commutateur particulier. Une classe peut très bien gérer certaines exceptions qui lui sont propres tout en déléguant une autre partie qui est à gérer par la procédure.

Même si on assimile souvent une exception à une erreur gérable, on peut les exploiter de manière beaucoup plus variée.

---

Tout à fait d'accord et un point que je trouve personnellement important réside dans le fait d'avoir un graph d'Exception; ainsi l'exception générée peut porter une signification et proposer elle-même des méthodes de traitement. On a trop tendance à oublier qu'une exception est une class comme une autre, avec toute la richesse que cela offre.

ERE

Tu viens de piquer ma curiosité avec ton "graph d'Exception"... tu peux m'éclairer ?

Pour le moment ma class d'exception qui étend Exception, se contente juste de formater un message d'erreur... qu'entends tu quand tu dis qu'elle peut proposer des méthodes de traitement ?

Salut,

Désolé pour le contre-temps. Ce que je voulais dire c'est que tu peux créer par exemple une class AdminException qui dispose d'une méthode prevenirAdministrateur. Quand tu génères l'erreur tu renvoies un objet AdminException que tu as remplis (par exemple localisation, message d'erreur interne, message d'erreur utilisateur, gravité...). Le développeur peut alors mettre un code qui ressemblerait à quelque chose comme:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

try { doTraitement(.....); } catch (AdminException $e) { if ($e->gravite>2) { //par ex: envoie d'un mail, log, ... $e->prevenirAdministrateur(); } echo 'Erreur: ', $e->getMessageUtilisateur() "; } catch (Exception $ex) { echo "Erreur: {$ex->getMessage()}\n"; }

---

Donc ton AdminException porte un service et n'est pas la uniquement pour sinifier qu'il y a eu une erreur. Et si tu gères l'héritage entre tes class d'exception (tu peux créer DaoException qui hérite de AdminException etc...) tu arrives à quelque chose que tu peux réutiliser tel quel dans l'ensemble de tes applications.

ERE

Citation:

---

Envoyé par emmanuel.remy

Désolé pour le contre-temps.

---

Mais y'a pas de mal :D

Ok, je faisais la même chose en procédural, concernant le fait de prévenir l'admin (donc moi) par mail en cas de grosse boulette.

Sinon pour l'organisation d'une telle class c'est encore un peu flou... mais je suppose qu'avec le temps çà va s'éclaircir.

Merci encore !