Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Bonjour
je suis sous zend 1.03 et j'essaie de personnaliser un peu mes message d'exceptions pour les rendre accessibles à des novices.
Je dois donc différencier beaucoup de cas et traduire les messages d'erreur de Zend en langage courant.
donc je fais actuelement ce genre de choses :
try { $rss = Zend_Feed::import($lien); } catch (Zend_Feed_Exception $e) { // l'importation du flux a échoué $err_msg = $e->getMessage(); if (strpos($err_msg, 'Feed failed to load, got response code 401')!==false){ // erreur 401 //Authentification HTTP : Demander user/pwd Header("WWW-Authenticate: Basic realm=\"Accès à un flux sécurisé\""); Header("HTTP/1.0 401 Unauthorized"); echo "Accès interdit !\n"; exit; }else{ echo "Une exception a été interceptée lors de l'importation du flux : {$err_msg} ".get_class($e)."\n"; exit; } }
Mais la comparaison de chaine, ca me plait pas trop. Je crois que quand j'etais sous JAVA, toutes les erreurs avaient un numéro qui permetait de les identifier. Je pensais que getCode me donerait cette information, mais cette fonction me retourne tout le temps 0.
Est ce que vous avez reussi a faire un test un peu de ce style :
switch ($e->getCode()){ case 111 : echo "Erreur d'authentification."; exit; break; case 76 : echo "Impossible de se connecter au serveur RSS."; exit; break; default: echo "Problème lors de la connection au serveur RSS.<br /> Erreur : {$e->getMessage()}"; exit; break;
Merci d'avance.
Pierre Bonneau
Hors ligne
regarde la classe Exception et notamment son constructeur.
Le code est passé au constructeur, or ZF n'utilise pas cette option.
(function __construct(string $message=NULL, int code=0)
Donc : si tu throw new Exception('Exception bidon',300); alors getCode() retournera 300.
Il te reste getFile() et/ou getLine(), ce qui n'est pas sans risque, en effet.
Dans ton cas très précis, tu peux dériver la classe pour utiliser le code réponse, ou faire une recherche sur le code de réponse avec un strpos.
Hors ligne
Au cas où, il y a une proposition en cours sur ce sujet : http://framework.zend.com/wiki/pages/vi … geId=22134
Mais ça n'a plus trop l'air de bouger... Tu peux toujours laisser un commentaire pour faire avancer les choses.
Hors ligne
Je suis aller voir le thread qui avait l'air arrêté depuis le 6 novembre. J'ai mis un petit message, a mon avis dan un anglais déplorable... pour appuyer en disant que sur le forum français il y avait des personnes intéressées par cette fonctionnalité. (problème de traduction entre autre)
Nous verrons bien si cela a quelques importance et si une date est fixée(ou une urgence...)
Merci en tout cas pour vos réponses.
Pierre
Hors ligne
les code d'erreur et les exception ne sont pas à destination du client mais du développeur
il est nécessaire de mettre en place des gestionnaire d'erreur (try catch) dans l'application pour les utiliser correctement.
c'est ainsi que l'application devient robuste.
d'un point de vu théorique je vous conseille de lire la prose de Meyer (inventeur du langage eiffel et de la programmation par contrat)
en gros on lève une exception lorsque la situation (dans le code local) ne permet pas de satisfaire la demande (la fonction ne peut être exécutée correctement)
Lorsque les arguments passé à la fonction ne sont pas conforme au prototype de la fonction on lève une erreur fatale (ça ne sert à rien d'essayer de dépatouiller une situation avec un code FAUT)
on traite l'exception le plus près possible du code qui l'a levée. éventuellement pour lever une exception plus adapté au contexte.
enfin au niveau général de l'application on place une capture de toutes les exceptions avec une trace de l'erreur dans un fichier de log (pour la supervision) et un écran indiquant l'indisponibilité de l'application pour l'utilisateur.
jamais une erreur ou une exception devrait aller jusqu'à l'utilisateur.
mais le monde n'est jamais parfait alors il arrive parfois que certain messages arrive jusqu'à l'utilisateur.
Bref ça ne sert donc à rien de faire un traducteur de message d'erreur car elle sont destiné au superviseur et au développeur.
A+JYT
Hors ligne
Je pense que dans ton cas tu perds une grosse capacité des exceptions à t'aider...
Par exemple dans le cadre du (pseudo) webmail que je fais, les exception me servent dans 2 cas :
->absence de sujet, d'envoyeur, de destinataire, etc... : cela génère une exception que je capture pour mettre un sujet vide ou un message affichant "Pas de sujet"
-> récupération d'une erreur 401 et envoie vers l'authentification HTTP
Sans compter bien sur que quand je recois une erreur du type :
invalid login or password, je pense que si je traduis ca par : login ou mot de passe invalide, mon utilisateur comprendra très bien.
Pour moi, les exceptions permettent de récupérer les comportements anormaux et d'assurer le traitement correct de l'exécution quand un de ces comportement apparait.
Le traitement correct pouvant etre une mise a une valeur par défaut, un arrêt du script, un thrown de message d'erreur personnalisé, etc...
Hors ligne
Pmithrandir a écrit:
Je suis aller voir le thread qui avait l'air arrêté depuis le 6 novembre. J'ai mis un petit message, a mon avis dan un anglais déplorable...
Il vaut mieux se manifester avec un mauvais anglais que pas du tout. Perso je n'hésite plus même si parfois je fais de l'anglais à la hache ! D'ailleurs je fais la même chose en français !
Dernière modification par 2mx (08-01-2008 10:28:02)
Hors ligne