Overloaded methods in stack trace

Question

There is a thing I thinking about.
When I have overloaded methods and I want to check a stack trace where one of these overloaded methods take part I cannot decide which method was in the frame, unless I have the source and have debug information in the class file.
It's not so painful because in most cases people have source code and compile with debug option if they need it, and so the method can be looked up.
Although, it makes harder to implement runtime test or error processing tools, which works upon stack trace elements. Methods could be annotated with version, author, date and other pieces of information. Runtime test or error processing tools could read and process these annotations.
Current StackTraceElement implementation makes this possible by using Reflection, while there are no overloaded methods in the stack trace.
It would be great to include some method into the StackTraceElement which return types of parameters of the stacked methods.
What's your opinion about this?
Here is a short source which demonstrates the problem:
public class Test {
     public void a() { throw new NullPointerException(); }
     public void a(int i) { throw new NullPointerException(); }
     public static void main(String[] a) {
           Test t = new Test();
           Random r = new Random(System.currentTimeMillis());
           if(r.nextBoolean()) t.a(); else t.a(0);
}I can't decide if a() or a(int) was invoked if I dont' have the source or haven't got debug info (line numbers).

Answer 1

I guess it would be quite useful in certain cases.
Let's say we make (runtime readable) annotations on methods with author, version and modification date information.
When we have an exception stack trace with exact information about concerned methods, we have all information to create and dispatch automatically an error report to the responsible persons based on annotations.