Discussion :

[casohite]

Voilà un 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
public class Test {
	public static void main(String[] args) {
		new Class2().fn2();
	}
}
 
class Class1 {
	public void fn1(Object obj) {
		System.out.println("The caller is : " + obj.toString());
	}
}
 
class Class2 {
	public void fn2() {
		new Class1().fn1(this);
	}
}

Donc avec ceci je peux déterminer l'objet (dans ce cas référencé par this) ou la classe qui a appelé la méthode.

J'aimerais bien savoir s'il y a une méthode ou n'importe quelle idée qui me permet de déterminer l'appelant d'une méthode dans le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Class1 {
	public void fn1() {
		System.out.println("The caller is : " + __caller__.toString());
	}
}
 
class Class2 {
	public void fn2() {
		new Class1().fn1();
	}
}

Ce que je cherche c'est une idée pour identifier une méthode ou un objet à mettre à la place de "__caller__".

[the-gtm]

C'est quoi le problème avec la première solution ? Tu n'as pas trop d'autre choix que de passer le caller en argument.

[®om]

C'est bien en passant l'appelant en paramètre que tu peux le connaître, il n'y a pas de mot-clé magique qui te le donne

[willy78]

Bonjour

Il a peu être une solution en passant un objet throwable en paramètre et d'extraire les infos de la stack trace. C'est ce que fait log4j.
Le code d'extraction des info est sur:
http://svn.apache.org/viewvc/logging...va?view=markup

L'appel a Category.info(xxxx) crée un LoggingEvent, qui utilise LocationInfo.

Ces informations ne sont dispo que si le code est compilé en debug.

C'est une piste possible.

[natha]

Sinon y a la possibilité d'utiliser le stack trace non ?

EDIT: En même temps que Willy

[the-gtm]

Oui enfin si la méthode est appelée depuis du code statique, ou par reflection c'est moins évident de dire qui est le 'caller'

[®om]

Utiliser un Throwable et la stack trace serait une grave erreur de conception...

[natha]

Utiliser un Throwable et la stack trace serait une grave erreur de conception...

Ca dépend si c'est pour du debug
Ca m'arrive parfois de faire des new Throwable() pour débugguer certaines méthodes qui plantent suivi un appel précis et pas un autre.

Mais évidemment il ne faudrait pas utiliser ça dans un logiciel fini.

[the-gtm]

Bof, pour voir qui appelle une méthode et si c'est en debug, il y a les debuggeur non ?

[sinok]

Il existe des personnes que les debuggers horripilent... (et je ne suis pas loin d'en être un en ce moment: vas faire tourner un debugger sur une instance de was quand tu as un PC limité à 1 Go de RAM, c'est la fête)

[natha]

Bof, pour voir qui appelle une méthode et si c'est en debug, il y a les debuggeur non ?

Je ne fais appel au debuggueur que quand je ne suis pas capable de détecter le bug seul sans trop passer de temps. En utilisant le débuggueur on passe parfois à côté de l'essentiel (même si on corrige le problème).

[adiGuba]

Salut,


On peut en effet utiliser le stacktrace. D'ailleur on peut utiliser directement par Thread.currentThread().getStackTrace()...

Toutefois il faut bien prendre en compte que la génération du stacktrace est très couteuse, et cela peut plomber l'application si c'est utilisé à outrance...

a++

[casohite]

J'ai besoin de identifier l'appelant d'une méthode quand je dois respecter la signature d'une méthode déjà indiquée dans une interface par exemple.

des modification de code précédant peuvent expliquer ça :

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
public class Test {
	public static void main(String[] args) {
		new Class2().fn2();
	}
}
 
interface AnInterface {
	public void fn1();
}
 
class Class1 implements AnInterface {
	public void fn1() {
		System.out.println("The caller is : " + __caller__.toString());
	}
}
 
class Class2 {
	public void fn2() {
		new Class1().fn1();
	}
}

supposant que l'interface est déjà définie ailleurs et on ne peut pas la changer . Comment on peut savoir qui appelle la méthode si on a besoin dans certains cas d'implementation?

[adiGuba]

Comment on peut savoir qui appelle la méthode si on a besoin dans certains cas d'implementation?

Franchement : j'ai vraiment du mal à voir l'intérêt de tout cela


a++

[®om]

Si tu en as besoin, c'est que l'interface est fausse... Donc tant pis