Calling a function recurcively

[someshr27]

Why the call to the function recurcively does not take it to any infinite loop.
class testMain
{
static int i=0;
public void callMe()
{
System.out.println("Call me called "+i++);
callMe();
}
public static void main(String a[])
{
{
try
{
String a [] ={"1,2"};
//System.out.println("Hello world "+(i++));
//Thread.sleep(100000);
new testMain().callMe();
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
}

[Ron Newman]

This won't compile for me. The 1.3.1 compiler says:
testMain.java:16: a is already defined in main(java.lang.String[])
String a [] ={"1,2"};
^
If I change the "a" to "aa" and compile and run it, I get a "Bus error" after "Call me called 4802". The catch(Exception e) doesn't catch this.
Even when I changed it to catch (Throwable e), the error wasn't caught. Any idea why? Shouldn't I have got an OutOfMemoryError?
[ November 07, 2002: Message edited by: Ron Newman ]

[Cindy Glass]

someshr27,
Please change your name to be compliant with JavaRanch's naming policy.
Your displayed name should be 2 separate names with more than 1 letter each. We really would prefer that you use your REAL name.
You can change your name: here.
Thanks,
Cindy

[Barry Gaunt]

Ron, on Suse 8.1 linux and java 1.41_01 I get Segmentation Fault, after 28000+ calls.
-Barry

[Ron Newman]

If you change the code to catch (Throwable e), will the error be caught in 1.4.1?

[Barry Gaunt]

Nope, same segmentation fault. Looks like it's broken some place, the JVM should behave a bit more gracefully that that.
-B

[Dirk Schreckmann]

Why the call to the function recurcively does not take it to any infinite loop?
If memory were infinite, then an infinite loop would be the result of a recursive algorithm that had no variant expression. But, memory is not infinite and each invocation of a method places a new activation record on the stack of activation records. These records take up space in memory. So, eventually all those activation records add up to more memory than is available.
Making sense?

[Dirk Schreckmann]

Ron & Barry,
I'm going to make fun of you for even suggesting to catch an Error!

[Ron Newman]

If you declare callMe() to be private or final, shouldn't the Java compiler do tail-recursion elimination, turning the recursive call into a goto?
[ November 07, 2002: Message edited by: Ron Newman ]

[Dirk Schreckmann]

I would guess and hope that the compiler does do some optimizing. In this case, whether final, I've not been able to create different results.
[ November 07, 2002: Message edited by: Dirk Schreckmann ]

[Jim Yingst]

If you change the code to catch (Throwable e), will the error be caught in 1.4.1?
I wondered that to, and just tested (on XP, using 1.4.1). Nope. If I run from TextPad, I get a message "Tool completed with exit code 128". If I run from the command prompt, or from Eclipse, it just terminates with no special message after approximately 4000 times through the loop (exact number varies). I also added a print statment after main to make sure it wasn't somehow exiting normally after the catch - no luck.

Shouldn't I have got an OutOfMemoryError?
Technically according to the API, OOME indicates the machine can't allocate memory for an Object - I.e. memory on the heap. What we have here is consuming memory on the stack. So I guess it makes some sense OOME is not thrown, but I'm not sure what the "right" response is then. Some sort of error seems appropriate. Very annoying.
I'm going to make fun of you for even suggesting to catch an Error!
Why? Sometimes it's the best thing to do. It may be risky, sure, but we are debugging after all. The program is already dying, so we're not likely to make things much worse. And even in production code catching an error may be appropriate when dealing with specific types of errors. E.g. catching an OutOfMemoryError may be OK if you can immediately free up some memory in response - something GC couldn't get to.
[ November 07, 2002: Message edited by: Jim Yingst ]