Alors là !!! Ca me sidère... !!    
 
Et en plus comme ca fait 1H que je cherche, ca me rend fou !!!    
 
Je parcours un fichier ligne par ligne, et je veux faire un traitement spécial si la ligne contient

Donc je fais :

 
Et bah ca me balance un NullPointerException !!!! Arghhhhh
 
 
Please help !
---------------------------------------------------------------------
 
Edit :
Le topic original ne parlait que de mon prb avec le equals, et avec cet edit, je rajoute mon prb avec le split !!!!
--> voir plus bas dans le topic :http://forum.hardware.fr/forum2.ph [...] 9#t1014160

Ca va être dur de t'aider si tu nous dis pas d'où sort la varaible 'lu'

C une bete string extraite d'un bete.txt:

(le tout dans une boucle while...)
 
 
Merci !

dcvlm> lu est probablement nulle.
 
y'a des gens qui justement conseillent de toujour écrire l'égalité à l'envers : "chaine".equals(variable)
 
ou dans Eiffel, y'a une fonction statique equals(v1, v2) qui prend en cherge le null.

Ca me dit toujours pas ce qu'est le 'lu'  
 
Bon sinon, c'est le readLine qui doit foirer

c'est une solution de facilité, mais faut pas prendre ça comme habitude : souvent la valeur null a une signification spéciale.
 
D'ailleur c'est le cas, là. => dcvlm, vas voir dans la javadoc de BufferedReader.readLine(), tu verras que ce n'est pas anormal que ca renvoit null.

FlorentG : lu est :

 
Et mon lu est absolument pas vide, parce que :
 
1/si je demande pas le if pr le traitement et que je fais simplement  

et bah ca marche tres bien
2/ Si je fais if(!lu.equals("new_topic" )), je ne rentre pas dans le if pour autant !
 
(rmq : ce sont des servlets, mais c'est presque trivial, non ??   )

nraynaud président !
 
En effet, ca marche très bien dans l'autre sens !!!!

t'as compris pkoi, au moins ?    

lu.equals("new_topic" )
 
 
d'où la recommandation classique
 
-> "new_topic".equals(lu)
 
et c'est blindé

je trouve qu'au contraire ca l'est pas ... en faisant ça tu fais 2 tests en un, mais y a souvent des cas où tu ne dois pas te comporter de la même façon dans les 2 cas.
 
J'ai déjà vu pas mal de bug à cause de se genre d'habitude => je conseille pas de systématiser ce genre d'écriture.

ben va le dire aux gens de Sun qui ont décidés de spécifier equals() comme ça. Et puis bon, si t'es capable de te souvenir qu'on compare les chaines avec .equals(), tu peux aussi te souvenir que si l'argument est null, ça fait faux.
 
Sinon tu deviens parano, et tu retrouves vie à écrire des
 
if(y == null) { return false; }
else { return x.equals(y); }
 
(c'est du déjà vu ça)

benou>> Non je n'ai pas compris pourquoi !
Si j'avais à connaissance la subtilité dont tu parlres --> bah j'aurais pensé à l'écire dans l'autre sens    
 
Sinon, j'ai une petite question : est-il possible de commencer à écrire au début d'un fichier plutot qu'a la fin ?
(soit c'est tout bete, soit je peux faire un nouveau topic si vous pensez que c'est nécessaire)..
Marci !

Salut, pour le equals j'ai fais un ptit test chez moi et ca marche très bien avec lu.equals("new_topic" ); ...
voila le code si t'as envi d'essayer par toi même
 

import java.io.BufferedReader;
import java.io.FileReader;
 
public class Coucou {
   public static void main(String args[]) {
      String lu="";
      try {
         BufferedReader in = new BufferedReader(new FileReader("coucou.txt" ));  
         while(in.ready()){
            lu = in.readLine();
            if(lu.equals("new_topic" )) System.out.println("yeah" );
         }
      }
      catch(java.io.FileNotFoundException e) {
         System.exit(1);
      }
      catch(java.io.IOException e) {
         System.exit(1);
      }
   }
}

while(in.ready()){
            lu = in.readLine();
            if(lu.equals("new_topic" ))
 
 
dommage, c'est toujours pas, ça fera toujours une NullPointerException ...
 
 
while((s = in.readLine()) != null)
   c'est pourtant pas compliqué
 
il serait de RTFM un minimum
 

et pourquoi ca ferait une exception ?
 
j'ai testé mon code et ça marche même avec un fichier vide
 
ce que tu as mis fonctionne aussi, mais pourquoi pas utiliser ready(), ca permet de savoir directement si le flux est prêt à etre lu
s'il renvoi faux c que le flux est fermé et donc que ya plus rien a lire... (fin de fichier)

parce que in.readLine() peut toujours retourner null  ce que tu ne gères pas ...

dans quel cas readLine() retournerait null ?  
 
si on arrive en fin de fichier, ready() retournera faux donc on entre pas dans la boucle while,
donc le readLine() ne s'effectuera pas
donc pas de NullPointerException

ton assertion est un peu bancale ... autant te baser sur la valeur retournée par readLine(), là c'est sûr.

je suis d'accord que la méthode de vérifier le retour de readLine() fonctionne
 
mais dans l'affaire, je veux juste dire qu'il existe la méthode ready(), qui a été créee exprès pour vérifier que ce genre de chose ne se produise pas
(vérification du flux entrant avant le readLine(), donc on aura jamais de NullPointerException)
 
 
enfin moi je ne fais qu'une suggestion, j'ai tester les 2 méthodes et   je sais très bien qu'elles marchent
c'est juste que je préfère faire ça avec les outils qui sont déjà à ma disposition
 
et puis il n'y a rien de bancale, tu n'auras qu'a faire tous les jeux d'essais possible par toi même, tu ne trouveras pas d'exception

non ready() n'a pas été crée pour ce genre d'usage, justement.
 
Et justement tu pourras avoir des NullPointerException malgré le fait que ready() soit true.

y a rien à vérifier. la documentation dit que readLine() peut renvoyer null. et la documentation de ready() ne dit pas que ready() est vrai tant qu'on a pas atteint la fin de fichier, et non plus si un appel à readLine() ne reverra pas null.
 
j'invente rien, RTFM
http://java.sun.com/j2se/1.5.0/doc [...] eader.html

ready() c'est juste pour savoir si le flux est immédiatement disposé à renvoyer quelque chose je crois ...en gros si son buffer n'est pas vide ...  
 
=> rien à vori avec un test valide sur la fin du fichier.
 
remarque quand même que contrarement à ce que dis taz, si ca retourne true, readLine retourne forcément autre chose que null, c'est plutot si ca retourne false que ca ne veut pas dire que readLine ne retournerait pas quelque chose de non null ...
 
en gros, là tu risques de ne pas lire la totalité de ton fichier.

http://java.sun.com/j2se/1.4.2/doc [...] ml#ready() plutot  

ok thx j'ai dla lecture  

jamais tu lis la doc ?

jamais tu lis la doc ?
 
 
edit : il a édité

c'est mieux

Ok j'avais tord    
 
readLine()
Returns:
A String containing the contents of the line, not including any line-termination characters, or null if the end of the stream has been reached
 
 
mais c bizzare, dns mon code jvérifiais pas que le retour de readLine() soit != null, donc ca aurait du lever une exception quand j'atteignais la fin de fichier  

 
String monObjet;
 
 
monObjet.equals("toto" ) => tu prends 'monObjet', un objet null, vu que tu n'as jamais écris quoi que ce soit dedans, et tu veux appeler une méthode nommée equals()... bref tu fais une sorte de NULL.equals("toto" ), et on peut difficilement demander au vide d'appeler la méthode equals()
 
Conclusion : NullPointerException
 
 
 
"toto".equals(monObjet) => tu prends "toto", c'est un objet de type String et non null vu qu'il "contient" le mot 'toto', donc tu appeles la méthode equals() de façon propre, depuis un objet qui existe. Bref tu fais une sorte de "toto".equals(NULL).... Après cet appel tout beau tout propre, la méthode equals() voit qu'on veut comparer toto avec NULL, et la conclusion est 'false' car dans 'toto' ya des lettres et pas dans null
 
Conclusion : Le code marche
 
Danger : "toto".equals(monObjet) se comportera de la même façon avec un objet NULL car jamais instancié (ca peut arriver dans un code pas propre), ou avec une string vide (et là par contre cela peut être une comparaison volontaire, parfois on récupère ""   )... on a le même comportement pour 2 choses différentes, ce n'est pas forcément une bonne chose

non sense! phaique! bot!    

 
     tu écrirais quoi toi pour expliquer ca ? Que c'est un pointeur vers null ? Pas sur qu'il connaisse les pointeurs

c'est une référence invalide sans instance derrière, c'est tout

tais toi, tôa
 
Xavier s'est fait chier à faire un gros post pour bien expliquer, alors respect

tu rames ou quoi ? null peut être vu comme un singleton (à cause du ==) d'une classe qui hérite de toutes les classes et interfaces du système (et cette classe existe réellement en Eiffel par exemple) et qui déclenche une NPE pour toutes les méthodes qu'elle implémente.
 
Cette approche permet entre autre dans le traitement des types et des variables de ne pas avoir de singularités à cause de la valeur null.
 
 
Il est absolument essentiel d'essayer de faire ce type de généralités quand on développe.
 

il aurait pu ouvrir le débat en parlant de l'approche d'Eiffel et de C++ par exemple

 
a toi l'honneur    
 

tain mes les singularités, c'est pas sale bordel (rien qu'à voir sur ce forum, y en a tout plein)

http://www.refactoring.com/catalog [...] bject.html
 
(http://www.owlnet.rice.edu/~comp212/00-spring/handouts/week06/null_object_revisited.htm,  
http://martinfowler.com/eaaCatalog/specialCase.html)

Je savais même pas que ça avait un nom ce pattern /o\
 

Donc voilà mon problème avec le split !!!
 

 
Et pas de bol, ca me balance encore un npe !!!      
 
Et, meme fort de l'enrichissement précédent....je ne vois pas comment retourner mon

!!!
Ca doit être la "nature" de lu qui doit être bizarre (mais je vois asbolument pas pkoi !!!), parce que pour me rassurer je me suis essayé au split ailleurs qd ds le cas d'une lecture de fichier, et ca marchait très bien !    
 
En attente de vos idées géniales

Pourquoi est-ce que tu ne fais pas de debugging pour regarder exactement ce qui se passe?