In JDK 1.5, you can use Thread.getCurrentThread().getStackTrace() to get an array of StackTraceElement objects representing the current call stack; the one at index 1 will tell you the name of the currently executing method (the zeroth one will be getStackTrace() itself.)
In JDK 1.4, you can create an Exception object and then ask it for its stack trace using getStackTrace(); the zero-th element will be the current method. Don't throw the Exception -- just create it.
In earlier Java versions, you can create an Exception, print the stack trace to a String, and parse it -- not for the faint of heart.
getName() is a method in junit.framework.TestCase class; you can call it from your test cases because you inherit in from this base class. It's not returning the method name, but a member variable in TestCase that holds the test name; by default, this is the name of the test method, but that's actually not required. In any case, it's set internally by JUnit.
Joined: Feb 03, 2005
Joined: Feb 03, 2005
....I guess I'll be writing my own "getName()" next.
You can always create a final variable (constant) in a method for logging purpose, as we do in our project:
final String METHOD_NAME = "doSomething()";
Joined: Feb 03, 2005
rathi, thanks... I'm trying to stay away from constants and hardcoding. I code back-end API Wrappers that all pretty much look & work the same to get to legacy data. As such I do a lot of "copy/paste/change" ("it is what it is" as my team leader says). I'm trying to make some utility methods so I don't have to change common code too much... again thanks.
But, good news... I have a working version of my method
I invoke the method like this: .... methodName = getMethodName(getClass().getName().length());
Are there any potential problems with my method?
[ April 26, 2006: Message edited by: Barb Rudnick ] [ April 26, 2006: Message edited by: Barb Rudnick ]
The javadoc for getStackTrace include the following warning:
Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this throwable is permitted to return a zero-length array from this method. Generally speaking, the array returned by this method will contain one element for every frame that would be printed by printStackTrace.
So this trick for finding the name of the current method is not infallible. But has anyone ever noticed this problem with stack frames? Sometimes in stack traces I see something like "blah blah blah compiled code..." Is that what's being referred to here? And could compiler optimizations like inlining methods also screw up the stack trace?
I've seen OutOfMemoryError with no stack trace - I think also StackOverflowError, on some systems anyway. Other than that, seems like the stack trace is most always present. It's possible some details get screwed up by compiler optimizations in some cases, but I can't recall ever noticing that effect.
As for "...compiled code..." messages - is it possible you're remembering the output from your IDE rather than a raw stack trace? IDE's will look at the stack trace and try to find source code that goes with it, and if you don't have the source (or the IDE doesn't know where it is), then you get a "compiled code" message. But usually that's still accompanied by a method and line number - it's just that the IDE can't show you the source. Maybe that's not always the case though.
Barb - another issue you might want to beware of is that creating a new Throwable may be a fairly heavy-weight operation (performance-wise) compared to most other things you might be doing. It's pretty minor compared to, say, accessing a database. But it could be huge compared to, say, multiplying two numbers. So in some contexts (like inside a short loop with many repetitions), you might want to avoid using this method. As with most performance issues, you won't really know how big an effect it is unless you measure it. Don't let performance paranoia prevent you from even trying this technique. But be prepared to limit its use if performance turns out to be an issue.