Dans certains contexte, il est important de pouvoir fournir des messages d'erreurs dans différentes langues, par exemple en fonction de langue de l'utilisateur.
Parmi les sujets à mettre en oeuvre pour adresser ce point, les exceptions et leur messages sont à ne pas oublier, voici une technique que vous pouvez mettre en oeuvre.
Tag - exception
mercredi, avril 14 2010
Externaliser les messages d'erreurs des exceptions, pour les internationaliser, par exemple
Par Olivier Hoareau le mercredi, avril 14 2010, 23:53 - Trucs et astuces
samedi, avril 4 2009
Typer vos exceptions: les types d'exception génériques mais utiles
Par Olivier Hoareau le samedi, avril 4 2009, 13:53 - Trucs et astuces
Si vous utilisez le mécanisme d'exception de PHP, vous devez savoir qu'il est possible de créer vos propres exceptions en héritant des classes Exception ou RuntimeException. (SPL), par exemple comme ceçi :
class MyException extends Exception
{
}
...
mardi, février 10 2009
Chasser les dépendances implicites : où comment rendre votre code moins obscur
Par Olivier Hoareau le mardi, février 10 2009, 09:04 - Méthodologie
En PHP, comme dans beaucoup d'autres langages, nous pouvons faire des fonctions et des méthodes qui prennent des arguments.
Prenons la fonction suivante : ...
mercredi, février 4 2009
De la nécessité de vérifier l'état des connexions/requêtes à la base
Par Olivier Hoareau le mercredi, février 4 2009, 11:41 - Méthodologie
Imaginez un site marchand sur lequel olivier@email.fr a un compte et sur lequel il fait un achat d'ordinateur, au moment de la validation et du paiement, nous écrivons en base de données : ...
lundi, octobre 27 2008
Tests unitaires et Exception : attention aux try/catch !
Par Olivier Hoareau le lundi, octobre 27 2008, 09:00 - Trucs et astuces
Les tests unitaires, pour ceux qui les utilisent, sont bien pratiques pour tester notre code. Malheureusement ils peuvent introduire, si ils sont rédigés de façon maladroite des problèmes qui peuvent être compliqués à comprendre a posteriori. Imaginons le code suivant (volontairement) mal codé : ...
Commentaires récents
Ah oui je confirme, ne jamais utiliser Exception car PHPUnit lui même les attrape.
De manière générale utiliser Exception n'est pas correct de toute manière ;-)
$this->setExpectedException('MonException'); est aussi possible depuis un test.
en effet, l'utilisation des transactions mysql avec un bloc try/catch est la meilleure solution, c'est celle que j'utilise aussi
Dans l'idéal, il faut vérifier toutes les valeurs de retour de chaque fonction utilisée, que ce soit pour les bases de données, la manipulation du système de fichier... J'utilise PDO pour mes connexions à la BDD, ce qui me permet de profiter des Exceptions pour gérer les erreurs liées à la base de données.
En sachant que l'utilisation des transactions en MySQL n'est pas toujours portable, cela dépend du moteur utilisé (ça marche pour les tables en InnoDB mais pas en MyISAM)
Pourquoi ne pas utiliser les exceptions définies dans la SPL (http://fr.php.net/manual/fr/spl.exc...) ?
Et à la limite :
class MaSuperException extends InvalidArgumentException { }
Cette approche a l'avantage selon moi de pouvoir définir un traitement différent selon les types d'erreurs rencontrés de façon générique, qu'elles soient levées par le langage ou par l'utilisateur (en tenant des journaux avec des niveaux de sévérité différents selon les types d'exceptions rencontrés).
J'utilise ce mécanisme en complément de la classe ErrorException (buggée en ce moment je crois) pour gérer tous les problèmes pouvant être rencontrés durant l'exécution des scripts.
Tu as tout a fait raison, l'utilisation des exceptions de la SPL est une bonne pratique.
Jusqu'à la version 5.3 (non compris), l'extension, packagée avec PHP par défaut, pouvait être désactivée. Depuis la 5.3 elle ne peut plus être désactivé, il n'y a donc plus d'excuse pour ne pas l'utiliser.
Cela ne vous empêche pas de rajouter certains type d'exceptions non prévus dans la SPL, avec parcimonie !
Sous drupal j'utilise la fonction t() pour traduire les chaînes de caractères.
Ex :
throw new Exception(t('Mon message'));
Au moins ça permet de regrouper toutes les traductions au même endroit.
le problème d'avoir juste un simple code numérique : le code source est moins lisible, et on a donc plus de mal à savoir quel est le message d'erreur, sans avoir aller chercher dans d'autres fichiers.
C'est pour ça que dans jelix, on a un compromis : on donne une clé alphanumerique, qui peut être beaucoup plus parlant qu'un simple nombre.
Par exemple,
throw new jException('jelix~errors.controller.class.unknown', $classname);
Et en fait, ça réutilise le système de localisation de jelix, qui se base sur un principe de clé->valeur plutôt que sur un truc du type de gettext.