java - Eclipse conditional breakpoint - only after other breakpoint

Question

I'm debugging an application that does a lot of method calling. I want to, for example, debug methodA. It is called 1000 times.

But, in my main loop, I only want to start debugging method A after a few statements.

public void methodA()
{
    //does something nasty that I want to debug
}
public static void main( String[] args )
{
    for (int i=0; i<1000; i++)
    {
        methodA();
    }
    methodB();
    methodA();
}

I want to start breaking in methodA only after methodB is called. I don't really want to change my code (say, inserting a boolean value and making the breakpoint conditional on that boolean).

Is something like this possible in Eclipse? Or are there better options?

Answer 1

A) Simply use hit count as 1000.

Its works only if the methodA inside for loop is NOT under some condition.

B) Using condition

Put the break point at the first statement inside methodA.Refer image

[Here methodA == test and I put break point at line number 14]

Right click on the breakpoint and select Breakpoint properties option and add the below condition.

StackTraceElement[] stacktrace = Thread.currentThread().getStackTrace();
StackTraceElement e = stacktrace[2];
return (e.getLineNumber() == 9);

Here 9 means the line number where second call to methodA(or test) is made.Find out the same in your code and change this.

Check the javadoc for StackTraceElement and instead of line number you can also use method name also. i.e you can break only when it is calling from the function xyz.

C) Wait for eclipse Oxygen (4.7)

In next version of eclipse JDT will provide trigger points on breakpoints. So you can say hit breakpoint y ONLY IF breakpoint x was hit before.

With this you can pause on a breakpoint ONLY on a given methods flow [stacktrace].

Ex: You can stop on a breakpoint only when call flow is:

methodA() --> methodB() --> methodC() --> methodD() NOT on

methodA() --> methodC() --> methodD() etc.

See this bug for more details. Add your comments/suggestion to this bug.