Reprise du message précédent :

tu m'es insupportable depuis le début  

merci  

donc j'ai rien fait de précis ...

 
developpe
 
(appel a la bagarre deguisé )

et ca me donne pas le droit de te trouver malsaine?

Ah oui aussi, je ne te supporte pas non plus mais pourtant je ne crois pas avoir dit quoi que ce soit sur toi ni sur personne d'autre d'ailleurs ...

tu penses ce que tu veux mais tu te le gardes pour toi ou tu m'en fait part en mp ...

tant mieux c'est réciproque alors!
grognasse

non, tu me cherches  

 
attention, coup bas, je te met 1 points de penalité et coupe la pomme en deux, mais que j'y reprenne plus

 
ah ouais ?

et moi je mange le reste de la pomme

mais pourquoi Darklord n'est pas là

 
han comment elle sacage mon arbitrage

et c'est tout ce que tu trouves à répondre ?
tres constructif ...

 
(cette replique foireuse me fait penser au combat d'insulte de monkey island 1)
 
(prochain episode : Et ta soeur ?)

alors moi va parler facile pour petit esprit
moi parler à reg toi problème
toi demander moi quoi problème
moi répondre
toi plaindre
moi dire toi que toi demander

 
(je signale que "ah ouais ?" ne vaut pas non plus grand chose comme repartie )

plouf ^\o/^

I already forgot
what I thought I would say
but all I wanna do is get off
I feel it I feel it I feel it babe
baby, come on
if you have a hard time gettin there
maybe you`re gone
if you find, you find yourself
against yourself
 

 
 
c'est la c'est pas moi qui est un problème hein ...
Tu ne m'aimes pas ok mais en quoi j'ai un problème ?

bah écoute, désolé, mais je n'ai jamais été un fan des exceptions. je ne renie pas leur utilité, mais je dis aussi qu'il ne faut pas en abuser car beaucoup de gens ont tendance à foutre tout leur code dans un try/catch et traitent l'exception comme des porcs. par exemple, hier, j'ai vu au boulot le code suivant sur un projet C# :

super, en gros ça veut dire "s'il y a une erreur, tu fermes ta gueule et tu fais comme si de rien n'était". OK, le gars qui a codé ça est un bourrin, mais ça existe...
quant aux baisses de performances, elles sont réélles si une exception est employée sur une boucle critique. testé en réél avec un profiler maison.là encore, c'est signe d'une mauvaise programmation, mais ça existe aussi...
beaucoup de gens gueulent sur le On Error machin de VB, alors que de mon point de vue c'est l'équivalent d'un try/catch !
 
il m'arrive d'utiliser les exceptions, mais dans la mesure du possible, si je peux me démerder autrement, et bien je n'hésite pas (en testant les codes de retour par exemple : sous Windows, y'a une fonction bien pratique qui s'appelle GetLastError())
 
voila, c'est mon avis quoi

peut-etre paske les 2/3 de ce topic ne t'apprécient pas  

bon les filles, engueulez vous en MP sinon c'est TT pour toutes les 2

 
 
et alors ? qu'est ce que ca peut me foutre ? tant que dans la réalité c'est pas comme ca ...
eh oui peut etre que ca peut te paraitre bizarre mais j'ai des amis qui m'apprécie comme je suis et pour ce que je suis et c'est pas toi, qui ne fait que lire quelques posts de moi sur un forum qui est la mieux placée pour me juger ...

j'en ai rien à faire tu vois

 
Disons que le pb avec les code de retour est -il faut etre honnete- qu'on en test pas la moitié parce que c'est sacrement chiant, relou et casse couille. Faire le porc avec les exceptions est evidemment possible, mais bon
 
La perte de perf de ta boucle tu l'as meme sans exceptions lancées ?

m'en fous de la réalité, moi je te juge sur le forum, en réalité ca serait peut-etre tout autre.
donc je maintiens mon avis  

Félicitation, tu viens de documenter ce qui s'appelle un "race condition" en appliquant un antipattern très connu.
il faut que la vérification de l'existance du fichier et l'ouverture soient dans la même transaction du point de vue système de fichier (ie le système de fichier ne peut être modifié de façon visible par ton application entre ces 2 actions). Sinon, il existe la possibilité de virer le fichier entre le test et l'ouverture (en général on fait ça en ralentissant à mort la machine).
 
regarde le manuel et tempnam(3) (la mauvaise manière) et celle de mkstemp(3) (la bonne manière) pour un exemple.
 
C'est encore un problème de concurrence à la con (puisque le risque ne vient même pas de ton application mais d'une application tierce).

 
ben maintiens ce que tu veux hein ...
ce qui m'importe c'est ce que les gens que j'aiment pense de moi ... toi à la limite que tu ne m'aimes pas ca va pas changer ma vie ...

alors continue de te faire passer pour la conne de service par ici (enfin je devrais plutot dire "continue ta cueillette" ) mais t'étonne pas que tu t'en ramsse plein la gueule!
un conseil: viens plus sur blabla@prog  

moi j'aime personne et je vous emmerde

 
ton conseil tu peux te le mettre ou je pense ...

 
C'est parfois (rarement) utile de tout catcher lorsque tu veux intercepter tout comportement anormale.
Par contre le catch vide, là c'est surprenant ... Ca peut arriver aussi, mais dans ce cas, moi je mets toujours uin commentaire pour expliquer la raison du ctach vide.
 

les codes de retour c'est une vielle habitude à la con !
c'était ok quand les langages n'étaient pas assez évolués pour proposer mieux, mais franchement c'est très limité !
Ca a tendance à m'ennerver quand je vois des codes de retour à tout bout de champ dans du code java !
C'est la meilleur façon de passer à côter d'une erreur grave ! et de se demander quelques semaines plus tard d'où vient ce putin de NullPointerException

kochone

allez prendre une douche froide, je vous libère dans l'après midi

C'est sourtout qu'avoir des valeurs singulières dans un type, ça veut dire qu'un gars va oublier de vérifier à un moment ou à un autre, que les fonctions ne peuvent avoir une image sur tout le type.
Par contre, c'est sur qu'on peut faire n'importe quoi dans un bloc try/catch.  
 
Je rappelle que dans la mesure du possible, on remet l'objet dans son état d'avant l'exception avant de la faire suivre vers la haut, ce qui permet au module d'au-dessus de savoir l'état exact de l'objet malgré l'exception (donc éventuellement de tenter quelquechose au lieu d'abandonner pour cause de non-visibilité).