Reprise du message précédent :

try {
  $validateur1->validate();
  $validateur2->validate();
  $validateur3->validate();
  $validateur4->validate();
}
catch (Exception $e ) {
  die('ya une erreur dans ton bordel');
}

Je crois que j'en ai eu besoin une fois

Oui mais non, on est déjà plus là dessus, faut suivre un peu on est au niveau d'en dessous dans la stack (et au niveau du dessus en abstraction)

C'est aussi (surtout) ce que fait django, dans la validation de formulaires (la validation de modèles est toujours pas include )

Mais chez eux, ça donne:

def full_clean(self):
    """
    Cleans all of self.data and populates self._errors and
    self.cleaned_data.
    """
    self._errors = ErrorDict()
    if not self.is_bound: # Stop further processing.
        return
    self.cleaned_data = {}
    # If the form is permitted to be empty, and none of the form data has
    # changed from the initial data, short circuit any validation.
    if self.empty_permitted and not self.has_changed():
        return
    for name, field in self.fields.items():
        # value_from_datadict() gets the data from the data dictionaries.
        # Each widget type knows how to retrieve its own data, because some
        # widgets split data over several HTML fields.
        value = field.widget.value_from_datadict(self.data, self.files, self.add_prefix(name))
        try:
            if isinstance(field, FileField):
                initial = self.initial.get(name, field.initial)
                value = field.clean(value, initial)
            else:
                value = field.clean(value)
            self.cleaned_data[name] = value
            if hasattr(self, 'clean_%s' % name):
                value = getattr(self, 'clean_%s' % name)()
                self.cleaned_data[name] = value
        except ValidationError, e:
            self._errors[name] = self.error_class(e.messages)
            if name in self.cleaned_data:
                del self.cleaned_data[name]
    try:
        self.cleaned_data = self.clean()
    except ValidationError, e:
        self._errors[NON_FIELD_ERRORS] = self.error_class(e.messages)
    if self._errors:
        delattr(self, 'cleaned_data')

(un form se valide en validant chacun de ses fields, et un field se valide tout seul comme un grand, sauf le cas particulier du FileField, et il y a des hooks au niveau du form pour pouvoir faire des validations supplémentaires sur un field)

 
Au niveau au-dessus c'est le même principe - enfin ça dépend comment tu hiérarchise ton process de validation.
Si t'as un validateur "formulaire" qui s'occupe d'appeler les bons validateurs champ par champ tu te retrouves avec le même bordel. Ta structure d'erreurs elle est dans le FormValidator, et pour la faire sortir sans exceptions tu vas forcément passer par un truc moche.

Bah non, tu la renvoies simplement et dans tous les cas, il n'y a pas d'exception ou de cas particulier

...et donc tu vérifies si ta validation renvoie null ou une instance de ton bordel d'erreur...cqfd.

Non, pourquoi ça renvoierait null

Et là encore, la structure d'erreurs n'est pas une erreur, c'est ce que tu demandes

Bon, avant de me tirer une balle je viens quand même demander ici
 
En ligne de commande :

echo iconv('utf-8', 'us-ascii//TRANSLIT', 'héhé');
// => hehe

 
Direct sur le site :

echo iconv('utf-8', 'us-ascii//TRANSLIT', 'héhé');
// => h?h?

 
Pourquoi ?

 
non
 
J'ai un fichier .php avec juste ça dedans :
 
<?php echo iconv('UTF-8', 'ascii//TRANSLIT', 'héhé') ?>
 
Et ça me sort h?h?
 
Alors que si je le fais en ligne de commande ( php -a ), ça me sort bien hehe ...
 
Je vais essayer de comparer les php.ini cgi/cli

Le fichier a bien le bon encodage sur ton serveur? Et est bien lu correctement? Parce que s'il est parsé en tant que CP-1252 ça va pas marcher

Alors attends. Tu dis que t'as de l'UTF-8 en entrée, mais ton source est-il bien encodé en UTF-8 ? Parce que sinon, ton iconv va se rater, non ? Puisque ton "héhé" dans ton source sera pas encodé en UTF-8, ba poum, décodage pourri.

EDIT : Masklinn

 
Oui oui, tout est OK, à l'affichage, ou avec l'utilisation de fonction de traitement sur le texte (remplacement, recherche etc.) y'a aucun souci.
 
Je bosse en 100% UTF-8 depuis un sacré bout de temps, tous mes softs de dev sont configuré comme tels.
 
Et la console est en UTF aussi.

Alors au hasard je dirais "vérifie avec un éditeur hexadécimal/un Notepad que t'es vraiment en UTF-8", on n'est jamais trop prudent et ça prend 2 secondes
Ensuite, plutôt que d'avoir des ? dans ton browser, essaie de savoir quel est le véritable caractère derrière (dumpe le résultat de l'iconv dans un fichier côté serveur). P'têt ça t'aidera à déterminer comment se passe l'encodage.

Ensuite, tu peux aussi choper d'autres sources de données UTF-8 (base de données, fichier plat, etc...) et tenter le même iconv pour voir. D'ailleurs, t'as déjà tenté de l'UTF-8 en direct dans un source PHP ? Ca s'était bien passé ? Et un iconv dessus aussi ou c'est ta première tentative ?

Rho ptin j'ai trouvé ... Faut rajouter un setlocale(LC_CTYPE, 'fr_FR.UTF8'); avant...

Donc maintenant faut que je vérifie dans mon FW, parce qu'il est censé faire un LC_ALL avec la langue courante

Merci de votre aide

Edit : Taiche > j'avais déjà testé tout ça. Et le "?" était un vrai "?", et non pas le navigateur qui ne savait pas quoi afficher. (d'ailleurs en allant dans Affichage > Encodage, j'étais bien sur UTF-8 aussi)

Mais non, t'as une méthode validate() qui retourne un booléen (ou FileNotFound), et du coup c'est tout aussi joli que tes Exceptions sorties de nulles part.

isValid  
 
validate() n'a aucune raison de renvoyer un booléen

Hmmm effectivement Ou areValid, vu que ce sont des données

Ça dépend comment c'est appelé. Après, c'est surtout une question de conventions: classiquement, dans les langages ne pouvant postfixer avec "?", le préfixe "is" indique qu'on récupère un flag.

C'était pour de rire
 
Mais je met toujours is, par convention effectivement

aussi joli ça se discute.
Mais bon bref, amha t'as tendance à ne pas utiliser les exceptions dans des cas où ça serait une bonne solution.

J'ai d'ailleurs été choqué de voir qu'en java on sort des exceptions tout le temps alors qu'en php c'est quelque chose de très rare.

ça a rien de choquant. Pour java c'est présent d'origine, pour php c'est un bricolage rajouté en version 4.

Héhé ouais    
 

Ouais peut-être. Mais je considère les Exceptions comme étant un mécanisme pour gérer les trucs super-exceptionnels genre nuclear meltdown.
 
Après y'a de toute manière 10 façons de faire la même chose, les goûts et les couleurs entrent en jeu. Trouve un truc qui te va, l'important c'est que ça fonctionne, et que ça te permette de sortir un bon soft

En Java y'a même les Checked Exceptions, du coup on voit beaucoup plus de try..catch

Regardes pas Python alors, parce qu'en Java les exceptions servent pour les erreurs, en Python elles servent pour n'importe quelle exception, pas juste des erreurs.

Bah c'est con. Comme leur nom l'indique, les exceptions ça a été créé pour gérer les cas exceptionnels, pas les cas "super-exceptionnels". Python s'en sert pour indiquer qu'un itérateur est épuisé par exemple (là où en java tu as Iterator.hasNext, en Python l'itérateur balance un StopIteration)

Oué mais ça c'était pas spécialement une bonne idée au final

 
Tu peux pas faire pareil en java en créant tes propres exceptions ?

Bien sûr que si, mais c'est pas dans la culture, alors qu'en Python si (la notation du "catch" python tend également a être plus pratique: tu peux "catcher" plusieurs types d'exception dans la même clause, alors qu'en java tu peux pas)

Ah ouais ils ont poussé le truc loin

Ca a quoi comme avantages précisément ?

Sinon c'est vrai que python peut davantage se le permettre.. En PHP un catchage d'exception c'est 6 à 8 lignes direct (parce que ces cons ont pas implémenté de syntaxe courte, je sais pas si c'est pareil en Java)

Assez oui. Et avec ça, la communauté a tendance à coller à EAFP: Easier to Ask for Forgiveness than Permission: au lieu de checker avant, tu lances ta commande et si ça pète tu gère l'erreur.

Typiquement pour sortir une valeur d'un k/v, en Python quand la clé n'existe pas ça balance une exception (au lieu de renvoyer null comme en PHP ou en Java), et au lieu de checker la présence de la clé pour pas avoir l'exception, habituellement tu récupères ton machin et tu catche KeyError au cas où

Par rapport à?
 

En PHP gérer une exception c'est

try {
    //whatever
} except (WhateverException $e) {
    // whatever
}

non

try {
    //whatever
} except (WhateverException $e) {
    // whatever
}

presque, catch au lieu d'except.

Autrement

try {
    //whatever
} except (WhateverException $e) {
    // whatever
}

Ouais, menfin ça reste verbeux et moi je fous les accolades au-dessous, donc soit je pète mes conventions, soit c'est 8 lignes
 
Et pas de débat sur la position des accolades, merci

T'es clair sur ce que tu veux faire (vu que tu le fais)

Oui mais ça s'ton problème si t'es pas très malin

Parce qu'en utilisant le 1TBS c'est pas beaucoup plus verbeux que l'équivalent en Python:

try:
    # whatever
except WhateverWhatever, e:
    # whateverwhateverwhatever

J'ai mon sens de l'esthétique

try:
    # whatever
except WhateverWhatever, e:
    # whateverwhateverwhatever

Ya pas beaucoup plus de lignes que ça, par contre ya des accolades partout (en plus des parenthèses obligatoires)

Difficile de l'utiliser tous les 3 statements sans donner un truc supra-laid...

Nan c'est pire, ça lève un warning (ou un notice, je sais plus) avant de retourner null, c'est plus rigolo

 
J'aime bien la façon dont ruby on rails s'en sert :
 

Chais pas ce que ça lève, mais c'est pas activé par défaut (je viens de test)