Reprise du message précédent :

 

 
Aux abris, ca va peter

mais j'ai pas le choix

 
bah j'imagine que vous allez un joru migrer a j#, ca ira tout de suite mieux

 
meme pas sure    
mais nous nous eloignons du sujet initial de ce topic...

 
tout a fait. D'ailleurs tu as soulevé un excellent point(tm) : la surabondance de catch() entraine une baisse de lisibilité dans le code.
 
Vaut il mieux alors faire :
->Une classe de base pour les exceptions (Genre IOException) et une peletté de sous classe pour tout les cas possible
->Faire une seule classe qui embarquera un flag indiquant le type d'erreur
->Les deux (sous classes + flag dans la super classe)
 
Le peu de cout de la troisieme version ainsi que sa flexibilité et le grain en lisibilité me ferait tendre vers cette solution.

Votre logique me déroute ...

 
  La solution de merde bien crade

solution 1 mais en version hiérarchique pour classifier un peu les 12000 sous-classes.

perso je ferrais la méthode de -- (si le fichier existe, on fait un bloc try/catch pour le cas où y aurait un autre type d'erreur)
mais y a une erreur dans les props du sondage :
"exist() + FileNotFoundException"
-> c'est un IOexception machin, pas filenotfound,

c'est déjà le cas de la IOException. Il y a pas assez de sous classe à ton gout mais elle entre dans ce schema ...

bha non, tu peux très bien catcher séparément la FileNotFoundException ... de toute façon la IO faudra la catcher. C'est la cas 1 ce que tu proposes.
 
Encore un qui a pas compris et qui du coup vote contre moi

 
ben moi j'ai voté pour toi   (mais je dis pas que ce que je/tu fais est ce qu'il y a de mieux, l'explication de Dark tiens le route )

 
dans l'exemple de code de -- y avait un if FileExist + un le catch de l'IO
dans ton exemple de code y a le catch de l'IO et le catch du FileNotFound.
je trouve juste que c'est plus joli un if qu'un catch pour le cas où ce fichier optionnel n'existe pas

Dites, elles durent cbien de tps la phase de modelisation chez vous ? parce que si il vous faut 2j, trois sondages et deux enquetes pour savoir si il vaut mieux faire un if ou un catch pour tester la presence d'un fichier, j'ai un peu peur pour un projet de bonne taille

Ca m'fait plaisir de lire ça, tiens

 
tu peux et' fier quand meme, t'as reussi a lancer du troll longue durée la

Mais j'ai pas dit le contraire bordel.

Dans ce cas, je vérifierait que l'utilisateur a bien saisi un nombre (je sais pas comment on fait en java, mais en VB on a la fonction IsNumeric() pour ça) plutot que de traiter ça par une exception.
 
Les 2 solutions sont justes, mais (moi, personellement, moi même,) je préfère n'utiliser les exceptions que quand je ne peux pas faire autrement de manière simple.

 
et plein de subtilité

autrement dit: "le C c'est hyper safe tant que tu ne programme pas avec"
 

je crois que c'est réciproque
 
 
Par curiosité, où as-tu apris à programmer ? et avec quel langage ?  
 
 

Tu ne voit pas la différence fondamentale de conception du monde que sous tend ces 2 méthodes ? Ne vois-tu point que selon le choix que tu fais, ta vie sera complètement différente ?
 
tu me déçois

Putain mais clairement +1
'tain, ils ont pas foutu les RegExp en 1.4 uniquement pour alourdir le JDK, hein Perso, quand j'veux un nombre, soit c'est une GUI et là vlan, j'empêche directement l'écriture des lettres et de la ponctuation (sauf . si jamais j'veux des floats), soit c'est d'la ligne de commande et là RegExp à deux balles, quoi.
Passer par parseInt() et NumberFormatException, c'est cheum Tu m'déçois sur ce coup-là, benou

Tu fais le boulot 2 fois, avec un parsing direct + catch tu ne passes qu'une seule fois sur le nombre. Dans ce cas c'est pas significatif, mais généraliser ce genre de comportement est une très mauvaise idée, t'as un code plus long, moins direct (le but, c'est bien de récupérer un nombre) et une complexité plus grande.

 
je vois pas pourquoi un if/else serait plus long qu'un try/catch  
 
 
Pour le reste, je crois que c'est une différence de point de vue et qu'il n'y a aucun intéret à argumenter vu que chacun restera sur ses positions.

 
pas "." bordel mais "decimalSeparator" (doit bien y avoir un équivalent en Java)
ça me gonfle les softs où je dois taper un "." alors que sur mon pavé numérique j'ai une "," et que j'ai bien configuré la "," dans les options régionales
 
surtout que j'ai déjà vu des softs mal foutus (peu importe le langage, mais je sais que cette erreur est facile à faire en Delphi) où il laissait passer le "." et pas les autres, mais faisait la conversion via une fonction qui tenait compte du séparateur défini dans le système :
- "." -> erreur de conversion
- "," -> je peux pas l'entrer dans le champ

Ui y a ça, c'est bon, on parle d'un exemple, en plus
 
 
(putain, chu aux trolls ce qu'un cochon est aux truffes )

 
on sait jamais, quand je vois certains guignols
c'était mon coup de gueule du jour

Et lever une exception, c'est gratuit peut-être ?

Roh, ça coûte un objet à peine, c'est pas un new qui plombe les perfos
 
 
 
...
 
 
 
Ah merde, si

ex1 :
  parsing 2x pour les saisies correctes, on pénalise l'utilisateur qui fait pas de gaffe
 
ex2 :  
  on pénalise celui qui se plante, ce qui n'est pas censé etre la majorité. Si on saisit un gros nombre, le double parsing est probablement plus couteux que le jetage d'exception.
 
je parierais sur l'ex2 en terme de perf globale sur un cas d'utilisation normal.

faut voir, parce que si en interne la fonction FileExist fait un gros try/catch pour tester si le fichier existe...

 
je mise aussi là dessus, l'exception est pas censé être levé sauf cas particulier, donc autant miser la perf sur la tournure normal du process

(c'est génial, ça part en latte dans tous les sens, suffit de poster un exemple et y a 10 posts qui se créent )

il faut voir aussi l'impact sur les perfs des 2 méthodes. si le parsing est aussi lourd ou plus lourd que la levé d'une exception, c'est sûr que tu as raison (à condition d'avoir des utilisateurs qui ne soient pas polios ce qui n'est pas gagné), mais si la levé d'exception prends une plombe, c'est pas sûr que la méthode 2 soit plus efficace.
 
Il faudrait savoir aussi ce que tu fais après aoir récupéré la saisie de l'utilisateur. Si tu t'engage dans un traitement long, la méthode 1 est est plus appropriée puisque l'utilisateur sera plus rapidement averti de son erreur éventuelle et dans le cas contraire, ça ne fait qu'allonger un traitement long de façon négligeable.

 
Bah effectivement, non : http://www-106.ibm.com/developerwo [...] =drs-j0504

 
la prochaine fois il fera attention à ce qu'il entre dans la case, c'est ca aussi la beauté de la chose, on eduque le user