guill76
Messages postés193Date d'inscriptionmercredi 24 août 2005StatutMembreDernière intervention 3 juin 2016 7 janv. 2008 à 19:22
Salut,
Bon pour le $e->closeConnexion c'est effectivement un truc qui me chagrine aussi.
Si j'intègre le close en fin de logIt ça résoud ce problème mais ça oblige à recréer une connexion à chaque exception et là ça me chagrine encore plus.
Donc je vais essayer de trouver une manière plus souple de procéder.
Pour une utilisation simultanée des 2 types d'exceptions, je n'ai pas coder ce besoin mais pourquoi pas..
"Est-ce vraiment le rôle de l'exception elle-même que de faire un tel traitement?"
Je pense que c'est assez subjectif, mais ta remarque est bonne(je me l'a suis faite aussi=> ta remarque :))
=>Pour moi étant donné qu'on peut avoir 1 évantail de classes d'exception indépendantes les unes des autres à sa disposition on est libre d'utiliser les exceptions qu'on veut et notament celles les + appropriée à ce qu'on veut faire.
Rien ne t'empêches en plus d'utiliser un systeme de log classique en //.
tout ça dépend également aussi de la manière de coder: par exemple si tu gères dans ton code toutes tes erreurs par exceptions là tu peux faire d'une pierre 2 coups (ça t'evites de lancer l'exception classique et à coté de faire du code en plus pour loguer tes erreurs dans un fichier log).
Et là c'était vraiment le but de cette classe dans mon cas.
Voilà et merci pour ta réaction.
cs_FredT
Messages postés65Date d'inscriptionmardi 18 février 2003StatutMembreDernière intervention11 avril 2009 6 janv. 2008 à 15:26
Salut
Si... ligne 214: if (!$result=mysql_query($queryTest),self::$oConnexionRes): parenthèse mal placée
Autrement, au niveau de l'idée, ça m'intéresse je suis actuellement sur le même sujet, je risquerai de revenir commenter dans qques jours.
Niveau du code y'a un truc qui me dérange c'est le fait de faire $e->closeConnexion();
dans le bloc catch: pas terrible à cette endroit, l'utilisateur de ta classe va les oublier à coup sûre
Niveau utilisation y manque quelque chose à mon goût, car tu peux soit enregistrer dans DB soit LOG, pas les deux. Pour aller plus loin... admetons que j'étende ta classe abstract avec une logMailException... je pense que tu suis l'idée... même si là le mot "log" commence à plus trop convenir. Mais on reste dans la même voie.
Autre point qui me dérange (je pense peut-etre un peu trop POO, mais si t'as réponse à ça, tu éclairerai ma lanterne.) Est-ce vraiment le rôle de l'exception elle-même que de faire un tel traitement?
Par définition on lance un objet Exception lorsque un bout de code entre dans un cas exceptionnel. Ce cas exceptionnel est testé et attrapé s'il a lieu (try) pour que dans le code utilisateur tu puisse parer à cet évènement (catch) .
guill76
Messages postés193Date d'inscriptionmercredi 24 août 2005StatutMembreDernière intervention 3 juin 2016 5 janv. 2008 à 13:14
7 janv. 2008 à 19:22
Bon pour le $e->closeConnexion c'est effectivement un truc qui me chagrine aussi.
Si j'intègre le close en fin de logIt ça résoud ce problème mais ça oblige à recréer une connexion à chaque exception et là ça me chagrine encore plus.
Donc je vais essayer de trouver une manière plus souple de procéder.
Pour une utilisation simultanée des 2 types d'exceptions, je n'ai pas coder ce besoin mais pourquoi pas..
"Est-ce vraiment le rôle de l'exception elle-même que de faire un tel traitement?"
Je pense que c'est assez subjectif, mais ta remarque est bonne(je me l'a suis faite aussi=> ta remarque :))
=>Pour moi étant donné qu'on peut avoir 1 évantail de classes d'exception indépendantes les unes des autres à sa disposition on est libre d'utiliser les exceptions qu'on veut et notament celles les + appropriée à ce qu'on veut faire.
Rien ne t'empêches en plus d'utiliser un systeme de log classique en //.
tout ça dépend également aussi de la manière de coder: par exemple si tu gères dans ton code toutes tes erreurs par exceptions là tu peux faire d'une pierre 2 coups (ça t'evites de lancer l'exception classique et à coté de faire du code en plus pour loguer tes erreurs dans un fichier log).
Et là c'était vraiment le but de cette classe dans mon cas.
Voilà et merci pour ta réaction.
6 janv. 2008 à 15:26
Si... ligne 214: if (!$result=mysql_query($queryTest),self::$oConnexionRes): parenthèse mal placée
Autrement, au niveau de l'idée, ça m'intéresse je suis actuellement sur le même sujet, je risquerai de revenir commenter dans qques jours.
Niveau du code y'a un truc qui me dérange c'est le fait de faire $e->closeConnexion();
dans le bloc catch: pas terrible à cette endroit, l'utilisateur de ta classe va les oublier à coup sûre
Niveau utilisation y manque quelque chose à mon goût, car tu peux soit enregistrer dans DB soit LOG, pas les deux. Pour aller plus loin... admetons que j'étende ta classe abstract avec une logMailException... je pense que tu suis l'idée... même si là le mot "log" commence à plus trop convenir. Mais on reste dans la même voie.
Autre point qui me dérange (je pense peut-etre un peu trop POO, mais si t'as réponse à ça, tu éclairerai ma lanterne.) Est-ce vraiment le rôle de l'exception elle-même que de faire un tel traitement?
Par définition on lance un objet Exception lorsque un bout de code entre dans un cas exceptionnel. Ce cas exceptionnel est testé et attrapé s'il a lieu (try) pour que dans le code utilisateur tu puisse parer à cet évènement (catch) .
5 janv. 2008 à 13:14