How many function calls will cause stack overflow

Question

Hello android/Java developers,

When a function call a function and that function call another one and so on, how many calls (stack length) would get me into stack over flow? Is there a general rule of thumb?

The reason i am asking is because I am now which is more efficient(design wise) for my 5 players cards game

Solution 1:

for(int i=0;i<100;i++){
         p1.play();
         p2.play();
         p3.play();
         p4.play();
}

Solution 2:

   p1.play();    //where p1.play() calls p2.play() and so on until p4 calls p1 again.   
                 // this will go on for 100 times

I prefer solution 2 so if there is a crash I can see all the function calls from p1 at i=0 till p4 at i=100

but with solution 1, the stack is much shorter but when there is a crash I will see on the beginning of the loops a the called function play() where crash happened

What do you suggest? I know it is kinda 2 questions in 1 but they are very related

Thank you all

Answer 1

In my experience, a stack overflow in Java is almost always due to a programming error. See typical sizes here.

Now, your second solution is, IMO, quite ugly... almost a programming error. Assuming N=100 is (sort of) the duration of your game, it sounds just wrong that the memory consumption (stack size) increases with it. I don't like that solution at all.

when there is a crash I will see on the beginning of the loops a the called function play() where crash happened

I don't see the real advantage. Why not put a try catch block so that in case of a crash you can print out the iteration number?

Answer 2

There is no general rule of thumb for recursive or nested functions creating a stack overflow. Instead it is dependent on the memory available on the stack, which may vary depending on underlying hardware and operating system allocations.

It is difficult to determine which method of function calls is better for your situation without seeing more of the code. I would side with the former (first) option because it is a little more explicit towards what is happening, and it avoids linking together possible methods and object instances that may not necessarily be dependent on one another. If you are primarily concerned by error reports, you can try adding Logs into your code to allow for more verbose knowledge of what is going on, along with looking at the dump of the stack trace. Hopefully this link can help you as well: http://developer.android.com/tools/debugging/index.html