JAVA : Transmissions de données entre classes

Bonjour,
En général, les blocs try/catch, c'estpour gérer des exceptions contrôlées, par exemple quand tu définis tes propres exceptions, et que tu les lèves de manière avoir pouvoir adapter un comportement en fonction du bon déroulement (ou non de ton programme).
Tu peux bien évidemment catcher des exceptions classiques pour adapter le comportement de ton application. Ceci dit, en général on ne catche pas des NullPointerException : quand tu as un NPE, ça signifie que tu essaies d'utiliser un objet qui n'a pas été instancié, donc :
- soit tu gères ça avec un if
- soit tu repères l'objet en question et tu l'initialises, parce que ça vient d'une erreur de programmation, et ça n'a pas à être traité comme un comportement 'normal' pouvant survenir dans ton application.

j'utilise socketclient.close() et MyServer.close(). Oui, mais ces trucs là, c'est des instances de quelles classes ? Tu les a créé comment ?
Donne nous le code qui a servi à les instancier, les appels aux constructeurs, et on pourra sans doute aller un peu plus loin.

Bonne journée.

Rebonsoir,

Alors un petit commentaire tout d'abord : en java, tes objets sont des références. Autrement dit, tu n'as pas de passages de paramètres par recopie comme ça se fait dans d'autres langages (sauf pour les types primitifs). Donc tu pourrais réécrire ton code comme ceci :

//Fonction de départ
public void Start() throws IOException{
try {
connect();
Speak(client);
}
finally{
client.close();
MyServer.close();
}
}

//Fonction de connexion avec création des sockets et renvoi le socket client qu'on
//doit réutiliser
private void connect() throws IOException {
MyServer = new ServerSocket(MyPort);
System.out.println("Listening");
client = MyServer.accept();
System.out.println("Accepted");
System.out.println(client.isConnected());
} 

En effet, dans ce cas, les références à MyServer et client de la méthode connect() référencent les attributs de ton instance de classe (pas besoin dans ce cas de les passer en paramètre, ou de les retourner (parce que quand tu fais client = MyServer.accept(), puis client = Connect(...), au final, c'est comme client référence le même attribut, c'est comme si tu faisais i=i, ça ne sert à rien).

Maintenant on va parler un peu d'exceptions. Imaginons une interface avec 3 classes : A, B et C.
A, c'est la classe sur laquelle l'utilisateur entre des données (par exemple dans un formulaire).
C, c'est la classe qui enregistre ces données dans une base de données.
B, c'est une classe intermédiaire.

Imaginons maintenant 2 cas :
- 1er cas : L'utilisateur entre une mauvaise information. Ton information est entrée dans A (méthode "enregistreDonnees()"), passe par B (méthode "passeDonnees()"), et vas dans C (méthode "sauve()"). Là, tu as une méthode de ta classe C qui détecte que l'information est erronée : tu lances une exception. Ici, comme c'est l'utilisateur qui est responsable de l'erreur, il convient de lui retourner cette erreur :
sauve sera affecté d'un "throws MonException", passeDonnees() aussi, et enfin, tu vas avoir un bloc try catch dans enregistreDonnees() afin de catcher les exceptions de type MonException, et d'afficher un message cohérent à l'utilisateur pour lui indiquer pourquoi ça ne marche pas.
-2ème cas : Même cinématique, sauf que l'exception n'est pas due à l'utilisateur, mais à ton application (par exemple la donnée que tu essaies d'enregistrer ne peut pas s'enregistrer parce que ta base de données n'est pas accessible). Dans ce cas, C va remonter l'exception ConnexionException à B, qui lui va la catcher pour faire un traitement transparent pour l'utilisateur (par exemple va stocker les données dans une file d'attente, lancer un timer et retenter de sauvegarder les données 30minutes plus tard).

Ces deux exemples, je les ai choisis pour te montrer que les exceptions peuvent être de 2 sortes : soit une erreur de l'utilisateur, auquel cas tu remontes l'exception au plus haut niveau pour l'en avertir, soit tout simplement un cas fonctionnel qui n'est pas "normal" dans le sens où en principe ça ne doit pas se produire, mais que tu gères proprement car "ça arrive tout de même quelquefois", et il faut bien que ton application tienne le coup.

Si je te dis tout ça, c'est parce que dans ton cas, ce que tu as fait ne sert à rien. Un bloc try sans catch, c'est inutile. Donc soit tu catches les IOException au lieu de les faire remonter, sois tu enlèves ton "try-finally".

Le fait que tu aies ici encore un NPE m'étonne car :
- MyServer = new ServerSocket(MyPort); Si une IOException est lancée depuis cet appel, MyServer ne sera jamais affecté, et tu auras une IOException ou une SecurityException, pas un NullPointerException.
- client = MyServer.accept(); Si une IOException est lancée depuis cet appel, client ne sera jamais affecté, et tu auras une IOException. Cependant en principe tu dois avoir une IOException et non pas un NullPointerException, donc je ne pense pas que ce soit le cas.

Le mieux pour toi est de (après avoir viré ton try-finally) remonter la pile d'appel pour déterminer plus précisément d'où vient le NullPointerException.

Cordialement

Hello,
Pourquoi tu laisse l'attribut client dans Speak ? Effectivement, il ne faut pas le laisser.

L'exception NPE se passe lorsque le client envoi *, c'est dire que ca finit speak ! Nous y voilà. Je cherchais désespérément pourquoi un NullPointerException alors qu'il ne devait pas y en avoir, mais en fait l'erreur est plus loin...

En fait c'est à cause de ton :

while(true){
 try {
  LineReceived = lecture.readLine();
  System.out.println(LineReceived);
  if(LineReceived.equals("*")){
   break;
  }
 }
 catch (IOException e) {
 e.printStackTrace();
} 

Tu lis bien le char '*', mais le problème est que tu ne sors pas de ta boucle infinie. A mon avis, LineReceived ne doit pas être égale à "*", mais plutôt à une chaîne du type "*\n". Si c'est effectivement le cas, ton code actuel ne te fait pas sortir de ta boucle, et au tour suivant, tu as ton lecture.readLine(); qui te retourne null, et donc si tu fais LineReceived.equal(...), tu as un NPE.

Bonjour,
Au temps pour moi, il ne faut pas mettre le '\n' :
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

En principe tu devrais donc sortir avec ton '*'. Ton System.out.println t'affiche bien '*' quand il faut? Peux tu vérifier que tu rentres bien dans ton if avant que ton programme se termine?

Merci

Hello Canaboss,
Alors tout d'abord, concernant ton code, j'avoue que je ne comprends pas. Les deux versions font strictement la même chose, donc je ne vois pas pourquoi la seconde marche mieux que la première... Enfin bref, ça marche c'est le principal, mais c'est déroutant tout de même.

Je suppose que ce que tu n'as pas compris, c'est le passage par référence, donc je vais essayer de te réexpliquer différemment.
En fait, vu la manière dont tu codes, on dirait que tu as appris à coder en impératif avant d'apprendre la programmation objet.
Je pense que tu connais le C, peut-être aussi le C++, donc je vais me baser sur des exemples simples (même si tu ne connais pas ces langages, tu vas comprendre).

1- Le passage par copie
En C :
int fonction(int a) {
return ++a;
}

int main(int argc, char *argv[])
{
int a = 5;
a = fonction(a);
printf("%d\n", a);
}

Ca affiche 6.
L'effet du passage par copie :
dans mafonction, a est alloué dans la pile. Quand tu le passes à mafonction2, ce n'est pas a qui est passé, mais un nouveau int est alloué dans la pile, et c'est cette copie qui va être utilisée dans mafonction2. Enfin, quand tu retournes a, un troisième int est copié dans la pile pour être retourné.

Le problème : bah tu écris en mémoire, donc tu 'perds' du temps, et surtout, tu écris des données qui ne servent pas forcément, et tu gaspilles de l'espace (ici c'est des objets légers, mais si tu passes un fichier de plusieurs Mo en paramètre, bonjour les dégâts, tu vas avoir un stack overflow à coup sûr).

2- Le passage par pointeur
Toujours en C
void fonction(int * a) {
++(*a);
}

int main(int argc, char *argv[])
{
int a = 5;
fonction(&a);
printf("%d\n", a);
}
Ca affiche 6 aussi.
Ici on passe le pointeur à la fonction, donc l'adresse en mémoire. Ca permet donc à fonction de modifier l'objet sans faire de copie, et donc pas non plus besoin de retourner l'objet vu qu'il a été modifié en mémoire (et non pas une copie comme dans l'exemple précédent). Les pointeurs c'est bien mais ça peut être dangereux car :
- si tu sais pas trop les utiliser t'as plein de fuites mémoire et de bugs
- tu peux faire des effets de bord

3- le passage par référence
Enfin, tu as le passage par référence en C++, qui ressemble fortement au passage par pointeur dans le sens où tu n'as pas de copie, tu passes une adresse. Mais c'est plus sécurisé parce que tu n'as que des droits limités sur la référence.

En java, à part pour les types primitifs (byte, char, short, int, long, float, double... j'en oublie peut-être) qui se font par copie, les objets sont passés par référence. C'est pourquoi quand tu fais :
Object o = new Object();
o = changeMe(o);

Ca ne sert à rien, car o est déjà modifié.

Je ne sais pas si j'ai été plus clair, mais je l'espère.
Cordialement

Rebonsoir,
Tu ne m'as pas dit que tu avais plusieurs threads, mais je ne pense pas que ce soit un problème de ce genre (qu'un thread initialise ton MyServer, puis qu'un autre le fasse pointer sur null avant que ton client ne l'utilise, je trouve pas ça crédible. D'autant plus que ce que tu fais actuellement fonctionne, et que finalement c'est la même chose).

Pour moi le mystère reste entier.
Si j'étais toi, j'essaierais simplement de poser des breakpoints dans Eclipse à chaque étape pour voir l'état de tes objets, et voir ce qui cloche juste avant la levée du NPE.

Cordialement