In general, having to know who called you would be a sign to rethink the design. You'd like a class to behave the same way for any and all clients who might use it now and in the future. If there is conditional logic in your method, base the logic upon a parameter or some other state, not who called it. That said, you can throw an exception, catch it, and parse the stacktrace information to learn the whole calling chain. People do this some times to display debugging information. But I'd still strongly avoid basing any logic on who called you. Hope that helps! If not, fill us in more on exactly the problem you're trying to solve.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
That said, you can throw an exception, catch it, and parse the stacktrace information to learn the whole calling chain. You can also skip the throw and catch, and just create a Throwable to get its stack trace. And note that since JDK 1.4 no parsing has been necessary - there's an API to get the stack info.
traces is used because traces is inside getCallingClass(), and traces is the method that called getCalling class. Which we probably already know - we want to know what class called that method.
There's no guarantee the stack trace will have the info we need; the JVM may leave it null in some cases. It may help to maximize the chance of getting info here by compiling with the -g option.
You could get class A to pass a reference to its instance (this) as a calling parameter and then use the above code to get the name.
The nice thing about Standards is that there are so many to choose from!
Joined: Jan 29, 2003
Thanks for the reminder on JDK 1.4. I've not used that yet, but it sounds useful. I'd repeat the advice to try real hard to not know who called you. Vasantha, do you have a really compelling reason? I can't think of any right off, but that surely doesn't mean there aren't any.
Joined: Jan 30, 2000
Should've mentioned previously - I agree with Stan's main original point too. It's rarely a good idea for a method to worry about who called it. The only exception I can think of is for logging, for debugging purposes. E.g. in java.util.logging.Logger, methods like entering() and exiting() shouldn't require the programmer to provide class and method names - that should really be done automatically, IMO. But unfortunately there's no guaranteed way for Java to provide this, as long as stack traces are considered to be optional. [ February 24, 2004: Message edited by: Jim Yingst ]
The question is, do you need to know the invoking object, or do you need to know about it? If you need to know something about that object, just provide parameters for it to pass the knowledge you require. Or you can have it pass a this reference as previously suggested. This is an uncommon technique because good design rarely calls for its use, but it can be a Proper Thing To Do given the circumstances. On the other hand, if you are somehow limited from having the invoking object pass in the appropriate knowledge, I would be highly suspicious that that limitation is in place for a good reason--it's probably part of the design and is not required for your situation. For that reason, I can say with a good degree of confidence that there should NEVER be a good reason to pull the caller's identity out of the stack trace, barring a few situations that are too bizarre to contemplate. sev