How can I find out which method calls my method?

I have 3 methods A (), B () and C (), both calls A () and B () C (). In the C () method, how can I find out its call from A () or B ()?

+2
source share
9 answers

I do not recommend this approach - other posters indicate the best way to handle this. But if you really need to know who called you without changing the C() parameters, you can do this:

 static void A() { C(); } static void C() { StackTrace st = new StackTrace(); Console.WriteLine(st.GetFrame(1).GetMethod().Name); // prints "A" } 

Please note that creating a StackTrace is somewhat expensive. However, it doesn’t matter if you do not do this in code that you call very often.

Again, you will almost certainly find a better way to do whatever you are trying to do.

+7
source

You do not need. Some method must perform a specific task, which is affected by its parameters and attributes of the object, and not the caller.

+11
source

Method C () does not need to know which method called it. If this is the way you handle the flow logic, you need to think again about how you write your code. If we assume that there is some good reason to know which method is called C (), I would create two wrapper methods: C_From_A () and C_From_B (). Any logic specific to the calling methods must be ported to the new methods, while the common code remains in the C () method and is called from both new methods:

 public void C() { // Common Code goes here } public void C_From_A() { // Code only to be called from A() goes here. C(); // Common code executed } public void C_From_B() { // Code only to be called from B() goes here. C(); // Common code executed } public void A() { // Other code goes here C_From_A(); } 

If you need to know for debugging, just use the debugger to execute your code.

+3
source
+2
source

An easy (and clean) way would be to introduce a new parameter C and A and B tell C who called it.

+1
source

Just set a breakpoint in C ()

0
source

I agree in principle, you do not need to know in most situations.

However, one use case, when it may be useful to know, is debugging when some information arrives, in case of an unsuccessful passed parameter.

However, in this case, it is probably better to throw an exception, register an exception and "restore" from it. Obviously, this depends on how often the method is called, since when creating an exception, there is always some overhead. If you need to do this for some other reason, I would suggest you take a look at your design first.

If you need callbacks, I would suggest that you do A and B and implement the interface and pass A or B as a parameter. An interface can have a method called a callback, and C can call A or B.

0
source

In the case when you are trying to find out where the "bad parameter" was passed, you only need to set a conditional breakpoint in this method or break VS into an exception to be thrown, and then you can check the call stack (debug menu, window, stack calls) to see the whole chain of callers (with arguments passed) to this method.

0
source
 MethodInfo callerMethod = new System.Diagnostics.StackFrame(1).GetMethod(); 

Useful if you are writing an audit / journal structure, but in fact YDNTN is used here. Plus it cost a fortune at runtime.

0
source

Source: https://habr.com/ru/post/1439107/


All Articles