From:           	"Zeljko Velaja" <zvelaja@club-internet.fr>
To:             	<java@u-strasbg.fr>
Subject:        	tester la validité d'une référence après une affec
   	tation par new
Date sent:      	Thu, 18 Jan 2001 01:19:39 +0100
Send reply to:  	java@u-strasbg.fr

Je suis entrain d'analyser le source d'une application, et j'y rencontre
assez souvent un code du genre :

Nom_de_classe variable = new Nom_de_classe();
if (variable == null) return;

Cela ressemble fort au test de validité des pointeurs sous C/C++ :

Nom_de_classe * pointeur = new Nom_de_classe;
if (pointeur == 0) return;

Tester la validité d'un pointeur en C/C++ a, parait-il, un sens, au cas où
la mémoire nécessaire ne pourrait plus être affectée. Alors sachant que
l'appli que j'analyse est en fait une traduction du C vers JAVA, je me
demande si ce test a une raison d'être en JAVA et si je ne ferais pas
mieux tout simplement de supprimer la ligne de test. Qu'en pensez-vous ?

From:           	"Chris F Ravenscroft" <ravens@col.bsf.alcatel.fr>
To:             	<java@u-strasbg.fr>
Subject:        	Re: tester la validité d'une référence après une a
   	ffectation par new
Date sent:      	Wed, 17 Jan 2001 16:46:20 -0800
Send reply to:  	java@u-strasbg.fr

Well, il me semble qui si les developpeurs voulaient effectivement tester
la bonne allocation des objets, ils devraient, en Java, faire quelque
chose du genre :

try{
  Nom_de_classe variable = new Nom_de_classe();
} catch(OutOfMemoryError e)
{
  leur_code_de_traitement_du_probleme (recovery?)
}

plutot...

Ou plus generiquement ils peuvent remplacer OutOfMemoryError par Error.
Pour rappel quand une erreur risque arriver dans le corps d'une methode
celle-ci n'a pas besoin de clause Throws, contrairement aux exceptions. Ce
qui fait que cette option ne t'a pas immediatement saute aux yeux.

-CR

----- Original Message -----
From: "Zeljko Velaja" <zvelaja@club-internet.fr>
To: <java@u-strasbg.fr>
Sent: Wednesday, January 17, 2001 4:19 PM
Subject: tester la validité d'une référence après une affectation par new


Je suis entrain d'analyser le source d'une application, et j'y rencontre
assez souvent un code du genre :

Nom_de_classe variable = new Nom_de_classe();
if (variable == null) return;

Cela ressemble fort au test de validité des pointeurs sous C/C++ :

Nom_de_classe * pointeur = new Nom_de_classe;
if (pointeur == 0) return;

Tester la validité d'un pointeur en C/C++ a, parait-il, un sens, au cas où
la mémoire nécessaire ne pourrait plus être affectée. Alors sachant que
l'appli que j'analyse est en fait une traduction du C vers JAVA, je me
demande si ce test a une raison d'être en JAVA et si je ne ferais pas
mieux tout simplement de supprimer la ligne de test. Qu'en pensez-vous ?

From:           	"Nicolas Delsaux" <nicolas.delsaux@free.fr>
To:             	<java@u-strasbg.fr>
Subject:        	Re: tester la validité d'une référence après une a
   	ffectation par new
Date sent:      	Thu, 18 Jan 2001 09:08:03 +0100
Organization:   	Miriad Technologies
Send reply to:  	java@u-strasbg.fr

Pas forcément, puisqu'en Java, la création d'un objet peut échouer pour
d'autres raisons qu'une sortie de la zone mémoire. Par exemple, si la
classe nécessite la création d'objets Class spécifiques, et que ces objets
ne peuvent être trouvés, une exception peut être renvoyée. Auquel cas
effectivement, on revient à un try...catch. Cependant, il doit
probablement exister des cas où la récupération d'un objet ne marche pas,
la méthode renvoie alors null et l'objet n'existe pas (c'est notamment le
cas pour les get() dans les collections).

Nicolas Delsaux

----- Original Message -----
From: Chris F Ravenscroft <ravens@col.bsf.alcatel.fr>
To: <java@u-strasbg.fr>
Sent: Thursday, January 18, 2001 1:46 AM
Subject: Re: tester la validité d'une référence après une affectation par
new


> Well, il me semble qui si les developpeurs voulaient effectivement
> tester
la
> bonne allocation des objets,
> ils devraient, en Java, faire quelque chose du genre :
>
> try{
>   Nom_de_classe variable = new Nom_de_classe();
> } catch(OutOfMemoryError e)
> {
>   leur_code_de_traitement_du_probleme (recovery?)
> }
>
> plutot...
>
> Ou plus generiquement ils peuvent remplacer OutOfMemoryError par Error.
> Pour rappel quand une erreur risque arriver dans le corps d'une methode
> celle-ci n'a pas besoin de clause Throws, contrairement aux exceptions.
> Ce qui fait que cette option ne t'a pas immediatement saute aux yeux.
>
> -CR
>
> ----- Original Message -----
> From: "Zeljko Velaja" <zvelaja@club-internet.fr>
> To: <java@u-strasbg.fr>
> Sent: Wednesday, January 17, 2001 4:19 PM
> Subject: tester la validité d'une référence après une affectation par
> new
>
>
> Je suis entrain d'analyser le source d'une application, et j'y rencontre
> assez souvent un code du genre :
>
> Nom_de_classe variable = new Nom_de_classe();
> if (variable == null) return;
>
> Cela ressemble fort au test de validité des pointeurs sous C/C++ :
>
> Nom_de_classe * pointeur = new Nom_de_classe;
> if (pointeur == 0) return;
>
> Tester la validité d'un pointeur en C/C++ a, parait-il, un sens, au cas
> où la mémoire nécessaire ne pourrait plus être affectée. Alors sachant
> que l'appli que j'analyse est en fait une traduction du C vers JAVA, je
> me demande si ce test a une raison d'être en JAVA et si je ne ferais pas
mieux
> tout simplement de supprimer la ligne de test. Qu'en pensez-vous ?
>
>
>
>

Date sent:      	Thu, 18 Jan 2001 10:16:29 +0100
From:           	Remi Forax <forax@univ-mlv.fr>
To:             	java@u-strasbg.fr
Subject:        	Re: tester la validité d'une
   	référence après une affectation par new
Send reply to:  	java@u-strasbg.fr

Nicolas Delsaux wrote:
> 
> Pas forcément, puisqu'en Java, la création d'un objet peut échouer pour
> d'autres raisons qu'une sortie de la zone mémoire. Par exemple, si la
> classe nécessite la création d'objets Class spécifiques, et que ces
> objets ne peuvent être trouvés, une exception peut être renvoyée. Auquel
> cas effectivement, on revient à un try...catch. Cependant, il doit
> probablement exister des cas où la récupération d'un objet ne marche
> pas, la méthode renvoie alors null et l'objet n'existe pas (c'est

NON, la valeur de return ne peux pas etre null par contre, il peux y
avoir
un certain nombre d'exception et d'erreur :
  LinkageError, ClassCircularityError, ClassFormatError,
NoClassDefFoundError,
  OutOfMemoryError, VerifyError, IncompatibleClassChangeError,
  IllegalAccessError, InstantiationError, NoSuchFieldError,
NoSuchMethodError,
  UnsatisfiedLinkError, ExceptionInInitializerError

et j'ai du en oublier :)

> 
> Nicolas Delsaux

Remi Forax

From:           	"Herve AGNOUX" <hagnoux@mail.club-internet.fr>
To:             	java@u-strasbg.fr
Date sent:      	Thu, 18 Jan 2001 11:04:26 +0100
Subject:        	Re: tester la validité d'une référence après une a    ffectation par new
Priority:       	normal
Send reply to:  	java@u-strasbg.fr

Le 18 Jan 01, Nicolas Delsaux a écrit :

> effectivement, on revient à un try...catch. Cependant, il doit
> probablement exister des cas où la récupération d'un objet ne marche
> pas, la méthode renvoie alors null et l'objet n'existe pas (c'est
> 

Pour une exception normale, new renvoie dans tous les cas une 
référence d'objet valide. L'objet peut être dans un état invalide, mais en
tous cas la référence est utilisable et elle est valide. Ce n'est pas
clair avec les Error et avec les RuntimeException, c'est au cas par cas
j'imagine.

Il ne sert donc à rien de tester la validité d'une référence après un
"new". Elle est valide.

Si tu fais comme dans ton exemple :

x = new X();
if (x == null)
..

Soit le new s'est bien passé et le x est différent de null, puisqu'un
constructeur ne peut renvoyer null. Soit il s'est mal passé et le
programme a lancé une exception, et il n'exécute pas le test avec if. Il
saute à la première clause "catch" utilisable. Donc, dans tous les cas, ce
test est inutile.


--
Hervé AGNOUX  hagnoux@mail.club-internet.fr
Faites vos sites avec des formulaires electroniques :
http://www.diaam.com