Reprise du message précédent :
 
Ça suffit de mixer le PascalCase et l'underscore_separated, on est pas en Ada  

, mais quand même

 
Avant d'utiliser getimagesize tu t'assures que c'est une image

Et j'vois pas le problème de mettre des exceptions partout, les exceptions c'est le bien

Ou alors faut passer la vitesse supérieure et mettre des conditions, mais c'est moins répandu comme idée

(à noter: le premier paragraphe du lien a Tord: les exceptions, c'est pas juste pour la gestion d'erreurs)

C'est justement un cas pas exceptionnel L'utilisateur peut se tromper par exemple lors de l'upload d'un fichier. Pas besoin de Try-Catcher une Exception pour ça. Si ma fonction retourne null, hop le formulaire affiche une belle erreur standard

Comme tu c'est bien t'auras vérifié deux fois.

FileInfo
http://us.php.net/manual/en/ref.fileinfo.php

Inclus depuis la 5.3, et sinon PECL

Edit : j'ai oublié de préciser que je l'utilise pour checker le (vrai) type mime du fichier

T'as raison tiens, avec une exception propre tu pourrais faire ça de manière générique au lieu d'avoir tes null dégeux
 
Tu check les magic bytes, c'est portable

Au lieu de try-catcher une exception du genre :
 

try{
$type = getImageType($img);
}
catch(CpasUneImageTonTrucException $e){
die($e->getMessage());
}

 
tu trouves que c'est plus lisible de faire
 

if(($type = getImageType($img)) === null){
 die("CpasUneImageTonTruc" );
}

T'as raison, je devrais plutôt retourner false

if(($type = getImageType($img)) === null){
 die("CpasUneImageTonTruc" );
}

C'est pas un die d'abord C'est dans la fonction de validation, et ça set une erreur Pas besoin d'exception-try-catch
 

 
die ou pas, l'exception restera plus lisible que la comparaison magique avec null dans le code appelant.

Non mais le résultat est le même hein

C'est subjectif
 
J'ai juste un :

if(!MFW_Image::checkImage($file)) {
  $this->setError(...);
}

J'vois pas comment c'est pas lisible

if(!MFW_Image::checkImage($file)) {
  $this->setError(...);
}

 
C'était pas checkImage tout à l'heure, c'était getImageType().
Et là tout ce que tu sais c'est que ça marche pas, t'as aucune idée de comment ni pourquoi si tu vas pas voir dans le appelé...

D'ailleurs checkImage() si c'est pour vérifier que ton fichier est bien une image c'est un super mauvais nom amha.

En vrai c'est "verification." Mais j'évite de poster des noms de fonctions en français ici, ça fait dévier du sujet toujours
 

Tout ce que je sais c'est que c'est pas un type d'image valide. Y'a pas besoin d'en savoir plus.
 

Ouais j'vais changer ça. J'ai quelques vieilles API qui traînent avec des noms de fonctions nazes

Dans ce cas-là ta fonction c'est bool isImage($file), et effectivement pas besoin d'exception, mais ça n'a plus rien à voir avec ton exemple du départ.

Bah si, ça pourrait être que le fichier n'existe même pas, c'est pas la même erreur que "image invalide" (PHP se comporte comment quand il n'y a plus d'espace disque à l'endroit où il tente d'uploader son fichier?)

Ouais voilà
 

Je checke si c'est une image valide uniquement si l'upload s'est bien passé évidemment Si y'a plus d'espace disque où si y'a une autre couille, PHP l'indique.

de toute manière tu ne fais que repousser le problème, c'est la fonction appelante qui va finir par balancer une CPasUneImageException du coup...

Nan Jamais d'Exceptions dans les fonctions de validation de l'input utilisateur.
 
Je garde les Exceptions pour les cas de fails massifs pas gérés. Une erreur de la part d'un utilisateur (tel qu'un fichier du pas bon type) n'est pas une exception, c'est au contraire un fait fréquent. Pareil pour les vérification de taille de fichier et dimensions de l'image, pas d'exception
 
Une Exception serait plutôt à utiliser si PHP reporte que le fichier a été uploadé, mais le fichier n'existe en fait pas -> là c'est gravissime, faut exceptionner.

Elle fait quoi la fonction appelante, dans ton exemple?

Laquelle ? Je suis perdu

Elle fout son bordel dans une structure d'erreur et balance le tout au template pour réafficher le formulaire avec des erreurs kivonbien, je pense

celle qui appelle ton faux isImage().

j'imagine, oui...donc au lieu de balancer une exception en cas de problème il crée une structure qui décrit le problème afin qu'il puisse être traité à la prochaine étape...wait, j'ai une idée pour cette structure si tu veux FloG, tu pourrais appeler ça une eksepssion?

Ouais mais y'a sûrement plusieurs erreurs dans le formulaire, j'vais pas écrire une Exception massive avec toutes les erreurs dedans ?
 
Je récupère les données POST et la liste des uploads (FILES), je transmet au validateur. Si les données sont pas valides, réaffichage du formulaire avec la liste des erreurs construite par le validateur. Si données valides, traitement puis redirection vers la suite.

Ça c'est pas intelligent par contre, au niveau le plus haut ce qui l'intéresse c'est de pouvoir afficher les erreurs dans le formulaire, et il peut y en avoir blinde, donc mieux vaut toutes les collecter en une seul fois dans une structure mappant field => error, s'plus samrt

http://emacsformacosx.com/
 
Toute la page est "écrite" en SVG

 
D'autant que ça permet de définir un message d'erreur précis *dans* la fonction qui le découvre, plutôt qu'à chaque endroit où elle est appelée...

...donc tu fais quelque part un truc de ce genre :
 

if(($errors = MyFormValidator::checkData($input)) == null){
$this->rePrintForm($errors);
}
else{
$this->printSuccess($input);
}

 
à la place tu pourrais faire
 

try{
   MyFormValidator::checkData($input));
   $this->printSuccess($input);
}
catch(ValidationException $e){
  $this->rePrintForm($e->getErrors());
}

 
 
Rien ne t'empêche de mettre toutes tes erreurs dans une exception qui englobe tout si ça t'arrange...et ça reste plus lisible amha

Voilà On y arrive. D'où l'extrême importance de bien évaluer dans quel contexte sera utilisée une fonction. Et les difficultés qui s'en suivent pour designer une API bien solide

Rien n'empêche de wrapper cette structure dans une Exception plus globale levée à la fin de la validation, le code sera toujours plus lisible.

Oui mais non, ça change rien au problème que ton API soit bête

D'autant plus qu'avec des exceptions, tu pourrais génériciser ta validation: tu boucles sur tes fields, t'appelle les fonctions méthodes de validation kivonbien, tu récupères les exceptions via leur supertype (genre ValidationError) (warning: si PHP sait faire, c'est pas dit ) et tu ajoutes le contenu de l'exception à ta structure d'erreur (l'exception sachant se formatter toute seule. Tu peux même directement stocker l'exception).

C'est simple, flexible et solide.

S'pas très utile ça, c'est exceptionner pour le plaisir d'exceptionner

C'est ce que fait Symfony, il catche les éventuelles exceptions validateur par validateur, et les fous dans une structure $errors...

Question de lisibilité, c'est tout.
J'aime pas les return de valeurs magiques, 0/1/null etc. et tests qui vont avec...

Hmmm faut que j'écrive un wall of text là. J'y réfléchi et j'écris tout ça ce soir

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