4

Is it possible to create a breakpoint where the condition is that its the start of the recursive process? In other words, the stack should only have one call to the function.

IE consider this workflow:

Main func -> call recursive func -> hit breakpoint -> continue -> recursively call self -> DONT hit breakpoint -> continue recursion.

David says Reinstate Monica
  • 19,209
  • 22
  • 79
  • 122

3 Answers3

6

Try this:

if(!Thread.currentThread().getStackTrace()[2].getMethodName().equals("this method's name"))
     // breakpoint

The 2 is because getStackTrace will return the actual getStackTrace method as part of the stack, your method name, and THEN the caller method, which we want.

DankMemes
  • 2,085
  • 2
  • 21
  • 30
1

I don't this why you want to corrupt your code to achieve this unless you are creating break point programmatically.

Keep the break point inside the recursive function then right click on the break point and select break point properties the enter hit count 1. After hitting the break point first time it going to be disabled.

Chandrayya G K
  • 8,719
  • 5
  • 40
  • 68
  • 1
    This isnt exactly what I wanted. This will only work the first time the recursive function is called from the top level. I want it to work every time the function is called from the top level. I might not have made that clear enough, sorry – David says Reinstate Monica Apr 11 '14 at 13:08
0

You will want to add a parameter to your recursive function who's job is to track the depth of the recursion. When you do the recursive call, pass in the current depth value plus one, so it increments on each call. Then set a breakpoint based on depth == 1. Something like this (factorial example):

public static int fact(int n, int depth)
{
  if(n <= 1)
    return 1;
  return n* fact(n-1, depth +1);
}

Alternatively, some IDE's allow you to set breakpoints based on the number of times a line of code is hit. You could try using that instead.

Simon
  • 2,840
  • 2
  • 18
  • 26
  • Adding a parameter is bad practice because it (1) requires cleanup and (2) requires refactoring of anyone calling the function (which again requires cleanup). Breaking on number of times the line is hit would only work the first time. – David says Reinstate Monica Apr 10 '14 at 16:43
  • Unless the ide has some built in functionality, that's the only way you are going to solve it (i.e. writing some code). What kind of solution were you expecting? You can just step thru the debugger and see what's going on, or you can temporarily edit the code. Adding such a parameter is not going to hurt anything, and it makes the function easier to debug. – Simon Apr 10 '14 at 17:44
  • Thats the problem, it CAN hurt things. This is a recursive function that is used in many places. You want to avoid changing parameters generally speaking. As for what I was expecting, look at the other solution. That is exactly what I was expecting: unobtrusive condition for the breakpoint. – David says Reinstate Monica Apr 10 '14 at 18:11
  • Adding that line of code is worse, IMO, as it serves no other purpose than debugging. Adding a depth parameter is far simpler and has many other uses. If you don't want to break the interface, simply move the code into another method with that parameter and inside the original method, call the new one with a depth of 0. – Simon Apr 10 '14 at 18:18
  • You aren't adding that line to the code, you are adding it to a conditional breakpoint that is designed to be unobtrusive and deletable at any time. I'm not sure you understand how a conditional breakpoint works, please read up on i: http://stackoverflow.com/questions/7194326/how-to-use-conditional-breakpoint-in-eclipse – David says Reinstate Monica Apr 10 '14 at 19:15
  • Yes I do, but not all IDE's incorporate it, and from the line above it looks like you are adding it to the code, given it's surrounded by and if statement, which it wouldn't be in a conditional breakpoint. – Simon Apr 10 '14 at 22:15