sauver score jeu dans fichier

**cocotomy** · 19/12/2006, 01h16

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...

**afrikha** · 19/12/2006, 04h29

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 .

**cocotomy** · 19/12/2006, 14h32

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
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
 
                 try{
                        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);
                }

Si je supprime

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
catch(IOException e){
                        System.out.println(e);
                }

Il plante.

Que dois-je faire? Merci !

**thibaut** · 19/12/2006, 14h39

Primo 3 try... catch... imbriqués c'est super super laid.

Secundo tu dis il plante, mais que se passe-t-il ?

**afrikha** · 19/12/2006, 14h41

Renomme l'exception en "ex" au lieu de "e" par exemple. Ce qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
catch(IOException ex){
ex.printStackTrace();
}

Et aussi pense à lire un bon cours sur java, tu en trouveras ici

**afrikha** · 19/12/2006, 14h43

Envoyé par thibaut

Primo 3 try... catch... imbriqués c'est super super laid.

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

**thibaut** · 19/12/2006, 15h54

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+

**adiGuba** · 19/12/2006, 16h11

Salut,

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...

Cela permet une fermeture propre des flux, tout en conservant une gestion unique des exceptions...

Envoyé par thibaut

Pour moi rien n'est plus parlant qu'un try... catch... finally... sur un seul niveau.

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) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
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
 
		BufferedReader in = null;
		BufferedWriter out = null;
		try {
			String ligne;
			// creation des flux
			in = new BufferedReader(new FileReader("source"));
			// lecture et copie des données
			out = new BufferedWriter(new FileWriter("dist"));
 
			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
		} catch (IOException e) {
			System.out.println(e);
		} finally {
			if (in!=null) {
				try {
					in.close();
				} catch (IOException e) {
					e.printStackTrace();
				}
			}
			if (out!=null) {
				try {
					out.close();
				} catch (IOException e) {
					e.printStackTrace();
				}
			}
		}

Chacune des solutions ont leurs avantages et leurs défauts...

>> 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++

**cocotomy** · 21/12/2006, 01h57

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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
            try{
 
                        FileWriter fw = new FileWriter("win.txt");
                        fw.write(meilleurstring);
                        fw.close();
 
 
                  }
                  catch(IOException exc){
                        //System.out.println(exc);
                  }
          }

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.
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 !

**thibaut** · 21/12/2006, 09h59

Une petite remarque:

Il faut mieux placer le fw.close(); dans le bloc finally comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
FileWriter fw = null;
try  {
  fw = new FileWriter("win.txt");
  fw.write(meilleurstring);
}
catch(IOException exc) {
  System.out.println(exc);
}
finally {
  if (fw != null) {
    try {
      fw.close();
    }
    catch(IOException e) {
      // Rien à faire
    }
  }
}

**mavina** · 21/12/2006, 12h10

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

**thibaut** · 21/12/2006, 12h12

Ca reste à voir parceque la sérialisation est assez couteuse

**yann2** · 21/12/2006, 12h14

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;

**mavina** · 21/12/2006, 12h15

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 ?

Envoyé par yann2

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.

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

)

Cordialement

Fred

**Kikito** · 21/12/2006, 15h57

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
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
BufferedReader in = null;
		BufferedWriter out = null;
		try {
			String ligne;
			// creation des flux
			in = new BufferedReader(new FileReader("source"));
			// lecture et copie des données
			out = new BufferedWriter(new FileWriter("dist"));
 
			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
		} catch (IOException e) {
			System.out.println(e);
		} finally {
			try {
				in.close();
			} 
			catch (Exception e) {}
			try {
				out.close();
			} 
			catch (Exception e) {}
		}

Je sais pas ce qu'en pense les puristes, mais ça donne un code clair et robuste à la fois.

**Baptiste Wicht** · 21/12/2006, 16h28

Envoyé par Kikito

Je sais pas ce qu'en pense les puristes, mais ça donne un code clair et robuste à la fois.

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

, 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.

**Kikito** · 22/12/2006, 11h30

Envoyé par wichtounet

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

, 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.

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"

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.

**mavina** · 22/12/2006, 13h05

Allez, un petit exemple de try catch avec un nom d'exception explicite plutot de de tout catcher :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
BufferedWriter monBuffer=new BufferedWriter(new OutputStreamWriter(System.out));
try
{
	int i=Integer.parseInt("coucou");
	monBuffer.write(i);
	monBuffer.flush();
}catch(NumberFormatException e)
{
	System.err.println("Le nombre entré est incorrect");
}catch(IOException exp)
{
	System.err.println("L'écriture dans le flux a échoué");
}finally
{
	//Fermeture des flux propre
}

C'est quand même bien plus clair que de faire un catch(Exception e) et un System.err.println("oh, une erreur"+e);

Cordialement

Fred

**Kikito** · 22/12/2006, 16h04

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
try{
//code du chargement du fichier de config
...
}
catch(Exception ex){
    throw new ConfigurationLoaderException("Impossible de charger le fichier de config",ex);
}

sauver score jeu dans fichier

Langage Java

Discussions similaires

Partager

Partager