Why? If the method needs information to make decisions, such info should be passed explicitly as a parameter; not implicitly based upon where it was called from.
Bear Bibeault wrote:Why? If the method needs information to make decisions, such info should be passed explicitly as a parameter; not implicitly based upon where it was called from.
I am asking this for inquiry purpose.
because I have to find from existing flow in a complex Project.
I can make sure that,that method is called by somewhere. But couldn't find the place.
Yes, this is possible, and I'll disagree with Bear that it's always feasible to pass the necessary information to the method.
At the spot where you need this information, start with StackTraceElement[] stackTrace = (new Exception()).getStackTrace() and examine what's in that array.
There are a couple of other options for this kind of investigation. You could use an IDE like Eclipse to find all the references to that method. This method assumes that you have the source code and you are only interested in calls made to the method from within the immediate project or workspace codebase. If there is calling code for which you don't have the source, you could set a breakpoint inside that method and run the program in a debugger, then examine the call stack every time you hit the breakpoint.
Ulf Dittmer wrote:At the spot where you need this information, start with StackTraceElement[] stackTrace = (new Exception()).getStackTrace() and examine what's in that array.
Or, to avoid having to create an Exception object
Thread.currentThread().getStackTrace()
It still might. From the source of Java 6 through 8:
dumpThreads is native, but if getStackTrace() is called on the current thread it just creates a new exception.
However, I must agree that Thread.currentThread().getStackTrace() looks cleaner.