find out where a function is called from.

[hreodbeohrt]

Hey!
I've got a method in one class . This method is being used in another class, but also in my main program.
Is there any way to do a check within the method to determine where it was called from?

The easy fix is to change the main program, but im not supposed to.


Thanks :)

[DiamondSoul]

What you'd have to do is pass an argument to said method indicating where it's being called from. Java has no built in functionality for checking where a method was called from. Unless you count forcing an exception to be thrown and caught and then looking at the stack trace, but that'd be a pain, not to mention being atrocious programming style.

[Junky]

Why do you think you need to know this? As a programmer writing a method you should not care where it is being called from. It should not affect the behaviour of the method. If you think it should then you have a smelly design.

[kennyman94]

you don't have to throw an exception. just do this:

public void myDebugMethod(){
new Exception().printStackTrace();
}

no exception is thrown and the only way you can even tell that an exception was created is because of the stack trace info that was printed to System.err.
if you don't want it printed to System.err, then you can replace it with this:

public void myDebugMethod(){
new Exception().printStackTrace(System.out);
}

Why do you think you need to know this? As a programmer writing a method you should not care where it is being called from. It should not affect the behaviour of the method. If you think it should then you have a smelly design.

that is not always true. While the behavior of the method being called shouldn't be affected, the system as a whole can be screwed up if a method is being called at the wrong time or in the wrong context. I myself have had issues where knowing what, when, where, and in what order a method being called was absolutely CRUCIAL to finding and fixing bugs in (relatively) complex systems. Unfortunately, I am unable to think of such a situation off of the top of my head.

[pbrockway2]

knowing what, when, where, and in what order a method being called

For that use a debugger which will allow you set break points and examine the stack.

Poking about with exceptions doesn't sound a good design to inflict on the end user who does not have any wish to fix bugs.

[Junky]

that is not always true. While the behavior of the method being called shouldn't be affected, the system as a whole can be screwed up if a method is being called at the wrong time or in the wrong context.

That is not the methods problem. That is the problem of the code calling the method. If the program crashes or some other unwanted behaviour occurs then it should be tracked as to why the code is executing at the wrong time and it should be fixed. You should not be fannying about in your method trying to foresee every possible problem that may occur when it is called and trying to code against those problems. Except where parameters are invalid but you still do not need to know where/when the method was called.

[JosAH]

While the behavior of the method being called shouldn't be affected, the system as a whole can be screwed up if a method is being called at the wrong time or in the wrong context. I myself have had issues where knowing what, when, where, and in what order a method being called was absolutely CRUCIAL to finding and fixing bugs in (relatively) complex systems. Unfortunately, I am unable to think of such a situation off of the top of my head.

That is just a debugging issue; if the code were correct, you wouldn't need this mechanism.

kind regards,

Jos

[kennyman94]

if the code were correct, you wouldn't need this mechanism.

if the code were correct there would be no need to debug. Unfortunately this is usually not the case. if only it were then there would be much fewer headaches when coding. Although i would think that the mechanism would be exceedingly useful when tracking the operation of concurrent programs to possibly identify race conditions.

[JosAH]

Although i would think that the mechanism would be exceedingly useful when tracking the operation of concurrent programs to possibly identify race conditions.

Don't count on it; from the getStackTrace() API documentation for the Throwable class:

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

kind regards,

Jos

[kennyman94]

@JosAH Thank you for making me aware of that.