Salut
 
j'aimerais savoir s'il existe un moyen de connaitre le nom de la méthode dans laquelle on se trouve, à l'exécution (l'idée étant de faire une méthode d'affichage d'erreur généralisée).

Non. A part en utilisant les stacktrace.

• En jdk <= 1.3 c'est difficile : il faut parser le flux que tu peux récupérer en faisant un e.printStackTrace() dans un buffer
• En jdk1.4 c'est déjà plus facile : tu peux récupérer les StackTraceElement d'une exception et tu peux récupérer dessus le nom de la méthode.
• En jdk1.5 c'est encore plus facile : tu n'es plus obligé de générer une exception pour obtenir les stackTrace : tu peux directement récupérer les StackTraceElement d'un Thread

ah le bon vieux currentContext de smalltalk.
 
 
Par contre, je suis étonné qu'un débutant ait besoin de ça. Que veux-tu faire exactement ?

C'est ce qui me fallait, merci.
 
J'avais besoin de ça pour un truc tout bête :
en plus d'afficher l'exception, je voulais afficher le nom de la méthode d'où elle était lancée (sans afficher toute la pile).
La solution était pas bien loin en fait  

 
pourquoi un debutant ?

c'est vrai, d'où tu sort ça ?

 
chouette ca  

il cherche pas encore tout seul dans les docs ?
 
 
par contre, je me suis planté : il avait effectivement besoin de ça (enfin, pas exactement du contexte courant, mais de celui d'une exception), exactement dans une des seules utilisations correctes de ce truc.

ouep.
 
je me suis toujours étonné qu'il faille passer par une exception pour pouvoir afficher la stackTrace. C'est quand même bizarer que ca ait pas été disponible avant  

Non, c'est un bordel monstre, mais c'est obligatoire pour les exceptions.
 
Il faut :
 1) retrouver d'ou vient tout le code qui a été exécuté (donc en cas d'inlining, il faut poser des marqueurs, aller chercher les méthodes)
 
 2) instancier tous les objets représentant la pile, chercher les arguments qui auraient dû être passés sur la pile (mais qui ne l'ont pas forcément été pour cause d'optimisation)
 
 
bref, c'est un vrai bordel pour l'optimiseur.
 
En plus en dehors des exceptions, il ne doit pas y avoir beaucoup d'utilisations à ça (en dehors de trucs très très dynamiques et inoptimisables : sérialisation de tâches dans le langage, manipulation du flux d'exécution, continuations).

non, mais moi ca me permettais de suivre le programme, un genre de debugger à moi et passer par les exceptions, c'etait chiant (en plsu je voyais pas le pourquoi)

ça ça se fait au niveau VM, il y a un protocole de dialogue avec les JVM.

c'est jouable en java aussi, y'a un paquets de frameworks AOP qui le font (savoir dans quelle methode on se trouve, ie acceder à la pile d'appels)

bah oui, tu lances une exception, tu la catches et tu regardes la stacktrace.
 
ou alors (si le temps ne compte pas) tu poses des balises en entrée et (plus dur) en sortie de fonction.

euh pour l'exception, vu le coût, je doute que les frameworks tel aspectj, aspectwerkz ou meme nanning (qui d'apres son auteur est moins performant) fassent ça.
 
par contre ils vont probablement brouter le bytecode à la volée, oui..

sinon au lieu de développer en spécifique un système de gestion d'erreurs, log4j fait ca de base aussi

moi je vote pour l'aop, splus propre

pas besoin de la lancer/catcher : suffit de la créer ...

'tain, t'as raison, je pensais que c'était le "throw" qui remplissait la trace, mais c'est le constructeur. C'est à moitié dangereux ça !