Version imprimable
Bonsoir ou Bonjour,
Voilà j'ai réalise un petit jeu avec Jbuilder. J'y ai placé des compteurs pour les scores (parties gagnées,parties perdues...).
Je voudrais sauver/lire le plus facilement ces données dans un (ou plusieurs) fichier(s).
Il me faudrait un code java genre,
x=contenufichier("xxx.txt");
contenufichier("xxx.txt")=x;
Enfin c n'importe quoi ce que j'écris mais il existe p-ê un moyen de le faire aussi facilement. Je reve p-ê...
En tout cas merci pour votre aide...
Je ne pense pas qu'il existe un moyen aussi simple de faire ça, mais ça ne veut pas dire que c'est compliqué. Regarde cet article sur java.io .
Merci pour ta réponse. J'y ai pris ce code pour lire le contenu du fichier et ca marche très bien.
Maintenant j'ai pris un code pour écrire ds le fichier (et je l'espere ecraser l'ancien contenu) mais j'ai un problème. Il me dit que "(IOException e)" est déjà défini. En effet j'ai "public void newgame1_mouseClicked(MouseEvent e)"
Voici le code :
Si je supprimeCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27try{ String ligne; //creation des flux BufferedReader in=new BufferedReader(new FileReader("source")); //lecture et copie des données try{ BufferedWriter out=new BufferedWriter(new FileWriter("dist")); try{ while((ligne=in.readLine())!=null){ out.write(ligne); //insérer un saut de ligne d'une manière portable out.newLine(); } out.flush(); //vider le buffer }finally{ //fermeture de out out.close(); } } finally{ in.close(); } } catch(IOException e){ System.out.println(e); }
Il plante.Code:
2
3
Que dois-je faire? Merci !
Primo 3 try... catch... imbriqués c'est super super laid.
Secundo tu dis il plante, mais que se passe-t-il ?
Renomme l'exception en "ex" au lieu de "e" par exemple. Ce qui donne :
Et aussi pense à lire un bon cours sur java, tu en trouveras iciCode:
2
3
4
d'abord,c'est pas trois try/catch imbriqués mais deux try/finally et un seul try/catch, ensuite si tu trouves ça laid c'est dommage car c'est la bonne façon de coder ;)Citation:
Envoyé par thibaut
Depuis quand c'est la "bonne façon de coder" de faire 3 niveaux d'imbriquation rien que pour une malheureuse ouverture de fichiers...
Mon cher afrikha essaie de pondre du code comme en entreprise et tu verras comment tu vas être reçu. Parceque lire ce genre de code avec des try... catch... des finally sans catch etc, c'est illisible et pas du tout maintenable.
Pour moi rien n'est plus parlant qu'un try... catch... finally... sur un seul niveau.
A+
Salut,
Cela permet une fermeture propre des flux, tout en conservant une gestion unique des exceptions...Citation:
Envoyé par thibaut
Ce que tu gagnes en imbrications, tu le perds par un bloc finally plus complexe (et donc potentiellement source d'erreur) et par le fait que tu agrandis le scope d'utilisation de tes flux (et qu'il ne sont pas forcément fermé au plus tôt... même si cela pose peu de problème) :Citation:
Envoyé par thibaut
Chacune des solutions ont leurs avantages et leurs défauts...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
>> cocotomy : tu as deux variables avec le même nom : tu dois en renommer une !
C'est bien beau de copier du code, encore faut-il le comprendre... sinon cela ne sert à rien !
a++
Merci beaucoup pour votre participation. Hier, suite a une erreur dans le code, tte mon application plantait. J'étais un peu paniqué vu que je dois remettre ce projet pour vendredi. Je me suis rendu compte qu''en fait, java avait écrit en boucle infini dans le fichier. Celui-ci faisait 10Go et c'est donc pour ca que tout plantait lol.
Enfin maintenant tout va bien et c'est ce qui compte. Pour écrire dans le fichier, j'ai trouver ceci qui est très simple d'utilisation.
Il me reste néanmoins un petit problème qui n'a strictement rien à voir avec celui ci-dessus. J'ai créé des jTextField que j'ai rendu cliquable pour pouvoir y changer le fond. J'aimerais maintenant le rendre non cliquable à la fin de l'application mais le setEnabled ne marche pas. Il doit y avoir une autre technique.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14try{ FileWriter fw = new FileWriter("win.txt"); fw.write(meilleurstring); fw.close(); } catch(IOException exc){ //System.out.println(exc); } }
Je pense qu'il est préférable de poser cette question dans un nouveau topic mais bon si vous avez une réponse, vous pouvez tjs la poster ici.
Merci encore pour tout ! :P
Une petite remarque:
Il faut mieux placer le fw.close(); dans le bloc finally comme suit:
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Coucou,
Pourquoi ne pas créer une classe MeilleursScores qui sauvegarderai tes X meilleurs scores (allez, va pour 10) avec des accesseurs, et sérialiser le tout ?
Non seulement tu pourras en sauvegarder 10 facilement (ce qui n'est pas le cas de la solution "bas niveau" utilisée ici), mais en plus tu utiliseras un concept avancé de programmation (la sérialisation) ce qui te permettra surement de réhausser ta note ;)
Cordialement
Fred
Ca reste à voir parceque la sérialisation est assez couteuse ;)
Bonjour {
Je ne suis pas sûr que la sérialisation soit vraiment adaptée pour ce genre d'opérations. Je veux dire que l'écriture dans un fichier est certainement plus judicieuse. Notamment si la classe MeilleursScores évoluent.
} au revoir; :aie:
Salut,
On parle bien là d'un projet de jeu a l'université, je veux bien qu'en entreprise le cout des concepts soit primordial, mais pour comprendre des choses comme la serialization, il faut pouvoir les utiliser. Si vous leur dites que ca coute cher, ils ne l'utiliseront jamais.
De plus, ca coute cher pour des grosses classes, ici dix malheureux int a serialiser, ça n'est pas la mort. Ajoutons à celà que la serialisation se fera en fin de programme (surement au moment ou le jeu dit "vous avez perdu, voici votre score"), donc au moment où on a le moins besoin de ressources, celà nous donne une bonne configuration des conditions pour utiliser ce concept, vous ne trouvez pas ? ;)
C'est à rendre pour demain, à mon avis ca ne bougera pas des masses, et la maintenance est nulle puisqu'après vendredi, le projet ne sera surement plus travaillé (eh oui je suis étudiant :aie:)Citation:
Envoyé par yann2
Cordialement
Fred
Pour en revenir à la gestion des flux pour ma part je trouve comme thibault la solution de l'imbrication trop illisible.
Concernant le bloc finally plus complexe par contre moi en général je ne vérifie pas s'ils sont null ou pas, le NullPointerException sera de toute façon gérer par le try/catch :
Je sais pas ce qu'en pense les puristes, mais ça donne un code clair et robuste à la fois.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Robuste, je sais pas trop... Tu as des try catch qui ne font rien, donc tu ne seras même pas averti en cas d'exception :roll:, de plus, il est déconseillé de faire un catch d'Exception directement, c'est mieux de catcher individuellement chaque exception. En plus, je préfère de loin faire un test sur out et in pour vérifier qu'ils sont null ou pas plutôt que de me prendre une NullPointerException.Citation:
Envoyé par Kikito
1) Ce n'est pas mon code, si je n'ai rien mis dans le catch, c'est que je ne sais pas ce que voudrais en faire la personne qui poste, pê un throw ? un mail d'erreur ? un printStackTrace() ? je n'en sais rien donc j'ai rien mis, j'aurais du mettre un "//ta gestion de l'exception"Citation:
Envoyé par wichtounet
2) Ensuite, je ne vois pas en quoi ce serait déconseillé de catcher Exception ?, si on veut pour toutes les exceptions le même traitement je trouve ça peu lisible et peu maintenable de mettre n catch qui vont tous faire le même traitement.
Le jour où tu as besoin de faire un traitement particulier tu sors l'Exception pour la traiter dans un autre bloc catch au dessus, l'Exception correspondrait au default d'un case si je veux imager pour moi.
Dans les sources java en tout cas il ne se gène pas pour mettre des catch sur Exception et je ne me rappelle pas déja avoir vu deux blocs catch de suite qui font exactement la même chose.
Ceci étant je veux bien une raison (le seul cas ou je suis d'accord c'est dans le cas où tu as un seul type Exception de lever dans un bloc try, dans ce cas autant mettre le nom de l'Exception on gagne en lisibilité) qui explique pkoi il faudrait catcher individuellement.
3) Après pour le test sur null oui ça je le conçois, c'est un peu comme les break/continue par exemple, y a les puristes et ceux qui visent lisibilité/éfficacité/maintenance je suis plus dans la seconde catégorie même si j'admet que l'autre se défend parfaitement.
Allez, un petit exemple de try catch avec un nom d'exception explicite plutot de de tout catcher :
C'est quand même bien plus clair que de faire un catch(Exception e) et un System.err.println("oh, une erreur"+e);Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Cordialement
Fred
Attention, j'ai dis lorsque les deux blocs font exactement la même chose, là ce n'est pas le cas puisque le message est différent.
D'expérience, sur des applis pros dans 70% des cas une erreur qui arrive sur un try gérant plusieurs types d'exception génère le même throw dans tous les cas avec une Exception propre à l'appli.
Pour prendre une exemple très simple quand j'ouvre un fichier de config XML, si la récupération des données plante on ne va pas lever une exception différente pour ParserConfigurationException, FactoryConfigurationError, SAXException, IllegalArgumentException, IOException... je vais faire un traitement du type :
Code:
2
3
4
5
6
7