En ce momentGenshin ImpactValhallaBreath of the wildAnimal CrossingGTA 5Red dead 2
Liste des sujets
Java, try { //ligne } ne s'exécute pas
Shishigami-kun
Niveau 52
19 juin 2018 à 12:04:40
Bonjour, alors voilà, je suis en train de coder une petite appli' qui permet d'intervertir des colonnes dans un fichier CSV. Pour l'instant, j'arrive à ouvrir le fichier et à lire son contenu, cependant, je me heurte à un problème J'aimerais insérer le contenu du fichier CSV dans un tableau pour faciliter la manipulation de celui-ci, donc j'essaye de créer un tableau dynamique prenant en compte le nombre de colonne dans le fichier et le nombre de ligne ! Pour cela j'ai coder 2 fonctions :
Cependant, j'ai un soucis avec la fonction Column(), puisqu'importe le fichier, j'obtiens 1 en sortie (la valeur d'initialisation de nbOccurrences). La fonction Line() quant à elle fonctionne impec'.
Ce que j'obtiens en sortie :
Je ne comprend donc pas pourquoi la fonction Column() pose problème, quelqu'un à une idée ? J'ai l'impression que c'est l'intérieur du try catch qui n'a pas l'air de s'effectuer (le sout(line) par exemple ne s'exécute pas).
Merci d'avance ! :P
Message édité le 19 juin 2018 à 12:06:00 par Shishigami-kun
_S0uL
Niveau 9
19 juin 2018 à 12:40:47
On peut avoir un extrait du fichier ? Je suppose que tu es sous windows donc si c'est toi qui a créé ton fichier sous MS Excel ça sera bien évidemment des ; (parce que fuck les standards) et pas des ,. Mais si il a été fait sur un autre pc ou si tu as modifié une variable dans MS Excel par exemple il se peut que ce soit le séparateur virgule qui soit utilisé.
Shishigami-kun
Niveau 52
19 juin 2018 à 12:47:44
Le 19 juin 2018 à 12:40:47 _S0uL a écrit : On peut avoir un extrait du fichier ? Je suppose que tu es sous windows donc si c'est toi qui a créé ton fichier sous MS Excel ça sera bien évidemment des ; (parce que fuck les standards) et pas des ,. Mais si il a été fait sur un autre pc ou si tu as modifié une variable dans MS Excel par exemple il se peut que ce soit le séparateur virgule qui soit utilisé.
Le fichier est un simple bloc note .txt que j'ai créer pour tester, et oui, il comporte belle et bien des ;
J'ai creuser un peu de mon côter, le try catch s'effectue bel et bien, cependant, c'est l'intérieur de ma boucle while qui ne s'effectue pas... j'ai mis des sout(test...) pour voir a quelle endroit le code s'effectuer correctement.
Je ne comprend pas car c'est pourtant la même boucle while utilisé dans la fonction Line (qui elle, s'exécute...)
_S0uL
Niveau 9
19 juin 2018 à 13:03:25
Ah mais c'est un objet BufferReader. Je ne suis pas expert en Java mais j'ai une supposition :
si ton code appelant ressemble à ça :
BufferReader b = new BufferReader (<params>);
int linum = Line (b);
int colnum = Column (b);
/* Affichage */
Alors quand tu appel column, ton pointer de position dans le buffer est déjà à la fin du fichier (essaie de faire deux appels à Line, le deuxieme renverra 1). Il faut que tu te replace au début du fichier.
Shishigami-kun
Niveau 52
19 juin 2018 à 13:19:39
Le 19 juin 2018 à 13:03:25 _S0uL a écrit : Ah mais c'est un objet BufferReader. Je ne suis pas expert en Java mais j'ai une supposition :
si ton code appelant ressemble à ça :
BufferReader b = new BufferReader (<params>);
int linum = Line (b);
int colnum = Column (b);
/* Affichage */
Alors quand tu appel column, ton pointer de position dans le buffer est déjà à la fin du fichier (essaie de faire deux appels à Line, le deuxieme renverra 1). Il faut que tu te replace au début du fichier.
Voici le code qui appel les fonctions Line et Column
Sur tes conseilles, j'ai modifier quelques peu le code est effectivement, lors d'un deuxième appel de Line(), j'obtiens comme résultat 0 !
Comment faire en sortes que le Buffer reprennent le fichier depuis le début ? Il y a une méthode où je dois tout simplement ré instancier l'objet BufferedReader ?
_S0uL
Niveau 9
19 juin 2018 à 13:46:32
Tu peux le marquer avant l'appel à Line et faire un reset avant l'appel à Column. Doc ici : https://docs.oracle.com/javase/7/docs/api/java/io/BufferedReader.html#mark(int)
Shishigami-kun
Niveau 52
19 juin 2018 à 14:34:32
Okay, merci beaucoup :D
Shishigami-kun
Niveau 52
19 juin 2018 à 15:40:12
Bon bon bon, encore un soucis et toujours avec un BufferedReader (mais pas le même cette fois-ci...)
Je souhaiterai lire 2 nouvelles valeur que l'utilisateur doit saisir (sachant que j'en lis déjà une au tout début du programme sans que cela ne pose problème...)
Voici la fonction qui me permet de saisir la valeur au tout début du programme :
Celle-ci fonctionne sans problème, je l'ai donc reprise en partie pour la réalisation des 2 autres fonctions (ne vrai, ce sont quasiment les mêmes fonction hormis les sout qui sont différents...)
Là encore une fois, je comprend pas ce qui cloche puisqu'à chaque appel de fonction, j'instancie un nouveau BufferedReader que je ferme à la fin de la fonction, le message d'erreur étant l'exception produite par le try catch
_S0uL
Niveau 9
19 juin 2018 à 16:22:48
in (ou System.in) est un fichier un peu spécial (au même titre que System.out) qui représente ton entrée standard (ce que tu tape dans la console va dans ce fichier en gros). Il est disponible et ouvert de base par la JVM (qui fait tourner ton code). Dans FileName tu ferme ce fichier (ce que tu fais aussi dans SecondChoice mais pas dans l'autre étonnamment).
Du coup maintenant que tu l'a fermé tu ne peux plus lire dedans et c'est là que tu catch une IOException (qui est peut être une exception un peu trop large pour ton cas du coup).
Shishigami-kun
Niveau 52
19 juin 2018 à 16:32:59
Donc pas de in.close() ? Parce que pour moi, je ferme le BufferedReader avec le in.close() et non le System.in.
De plus, je viens d'essayer avec/sans in.close() (d'ailleurs merci, je n'avais pas vu que j'avais oublier le in.close() dans FirstChoice()) et cela ne fonctionne toujours pas, or, si j'ai bien compris ton message, j'aurai du être en mesure de pouvoir écrire quelque chose puisque j'avais enlevé in.close()... Est-ce que le fait que ce soit dans des fonctions différentes pose problème ?
Message édité le 19 juin 2018 à 16:36:44 par Shishigami-kun
_S0uL
Niveau 9
19 juin 2018 à 16:55:37
Oublie mon précédent message :D J'avais pas lu les lignes du dessus!
Du coup: D'après la doc, quand tu ferme un BufferedStream il ferme toutes les ressources systèmes qu'il à utilisé. Donc le InputStreamReader qui se trouve dessous est fermé. Doc de InputStreamReader.close () même chose. Donc ça cascade. System.in étant un InputStream il sera bel et bien fermé par cet appel à close. Il faut donc trouver un autre moyen pour lire ton entrée. Ce que je ferai grosso modo :
/* Programme principal */
n = new BufferedReader (new InputStreamReader ( System.in);
FileName (in);
FirstChoice (in);
SecondChoice (in);
in.close ();
return 0;
Puis tu adapte tes fonctions pour prendre un BufferedReader en paramêtre. N'oublie pas les exceptions et t'es bon je pense. N'hésite pas à lire la Javadoc, elle est vraiment bien faite, super facile à naviguée et parfois plus compréhensible qu'une recherche sur internet.
Shishigami-kun
Niveau 52
19 juin 2018 à 19:21:48
Merci beaucoup d'avoir pris de ton temps pour m'aider, je testerai t'as solution demain ! ;) Pour le problème, si j'ai bien compris, c'est qu'en effectuant le in.close(), cela cascade dans l'arborescence et finis par fermer également System.in ? Mais de ce fait, pourquoi ne se réouvre t-il pas quand j'instancie de nouveau un BufferedReader ?
Shishigami-kun
Niveau 52
20 juin 2018 à 09:20:37
Je viens d'essayer tasoluce et sa marche nickel ! ;)
Une dernière question, pour l'instant, les fichiers je dois les mettres dans le repertoire du projet, cependant, lorsque je l'aurais compiler en executable .jar, comment va se dérouler la recherche de fichier ? Est-ce qu'il faudra que le fichier lu soit dans le même repertoire que l'executable ?
_S0uL
Niveau 9
20 juin 2018 à 10:23:52
Pour le problème, si j'ai bien compris, c'est qu'en effectuant le in.close(), cela cascade dans l'arborescence et finis par fermer également System.in ?
Exact
Mais de ce fait, pourquoi ne se réouvre t-il pas quand j'instancie de nouveau un BufferedReader ?
Dans l'"arborescence" d'objets c'est toi qui doit créer les plus bas pour les passés au dessus. BufferedReader ne peut pas ouvrir un StreamReader de lui même si tu ne lui en passe pas un déjà créé (new BufferedReader (new InputStreamReader ( System.in);) et idem pour l'InputStreamReader.
Une dernière question, pour l'instant, les fichiers je dois les mettres dans le repertoire du projet, cependant, lorsque je l'aurais compiler en executable .jar, comment va se dérouler la recherche de fichier ? Est-ce qu'il faudra que le fichier lu soit dans le même repertoire que l'executable ?
A priori c'est à toi de décider. Soit tu dit que ton programe va chercher ses fichiers dans un certain répertoire, soit tu passe le répertoire en tant qu'argument à ton programe. Si tu ne veux pas t'embêter et que c'est un petit programme pour un TD ou quoi je pense que c'est raisonnable de dire que le fichier doit se trouver dans le même répertoire. Si c'est un truc un peu plus sérieux, il vaudrai mieux que ton programe soit paramétrable pour spécifier le chemain ou possède une interface permettant de spécifier un fichier à chaque run par exemple.