As far as I know this code should throw StackOverflowError, but it isn't. What could be the reason?
public class SimpleFile {
public static void main(String[] args) {
System.out.println("main");
try{
SimpleFile.main(args);
}
catch(Exception e){
System.out.println("Catch");
}
finally{
SimpleFile.main(args);
}
}
}
An Error is not an Exception. So catching any exception won't catch the StackOverflowError.
So lets start by fixing the "obvious mistake" - (this code is inadvisable as stated later in this answer):
catch(Throwable e){
System.out.println("Catch");
}
If you make this change you will find the code still does not print. But it doesn't print for a very different reason...
Catching any ERROR (including a StackOverflowError) is highly discouraged. But here you are not only catching one, you're catching one as it happens at the top of the stack. Even with your code (without the above change) the error is effectively caught by the finally block.
A StackOverflowError occurs when the stack is full and you try to add more to it. So when you catch the error the stack is still full. You can not call any method (even to print to the console) because the stack is full. So a second StackOverflowError is thrown in the catch before it has successfully printed.
The result of this is that it:
finally, because finally is always called.mainThe key here is that eventually it will start printing something. But the call to print uses a lot of stack space and your code will have to recurs and error through the above points for a very long time before it ever frees up enough stack space to print. According to Holger's comment With Oracle’s Java 8 to put the number of main stack frames needed for a println stack frame close to 50.
250 = 1,125,899,906,842,624
This is why YOU SHOULD NEVER CATCH ERRORS.
There are only a handful of excuses that allow you to break this rule, and you've discovered first hand what can go wrong if you do break it.
Actually you got java.lang.Stackoverflow
You can run this sample code:
public class SimpleFile {
public static void main(String[] args) {
System.out.println("main ");
try{
SimpleFile.main(args);
}finally{
try{
SimpleFile.main(args);
}catch(Error e2){
System.out.println("finally");
throw e2;
}
}
}
}
PS
More details: your program prints a lot of main messages and after this you receives stack overflow error for first time and go to finally block. It means that you decrease stack size and now you can call something. But you call itself in finally block and get stack overflow again. Most surprising for me was unstable output:
main
main main finally
main
main main finallyfinallyfinally
main
main
First, you have a catch clause which doesn’t catch Errors:
catch(Exception e){
System.out.println("Catch");
}
Since Errors are not Exceptions, this does not catch StackOverflowErrors and the print statement will not get executed. If an Error is not catched, it’s stack trace will get printed by the default handler of a thread, if it ever reaches that point. But you have another clause:
finally{
SimpleFile.main(args);
}
The code of the finally clause will always get executed when the try block completes, whether normally or exceptionally. Since your try block contains an infinite recursion, it will never complete normally.
In the exceptional case, i.e. when a StackOverflowError is thrown, the finally action will go into into an infinite recursion again, which may again eventually fail with a StackOverflowError, but since it bears the same finally block, it will also go into the infinite recursion again.
Your program is basically saying “perform an infinite recursion, then another infinite recursion”. Note that you can’t distinguish from the printing of "main" whether the program runs in the primary infinite recursion or one triggered from a finally block (except that line breaks might be missing if a stackoverflow happens right in between the println execution).
So if we assume that a particular JVM has a limit of 1000 nested invocations, your program will perform 2¹⁰⁰⁰ invocations of your main method (quantification). Since your main method actually does nothing, an optimizer could elide even this incredible number of invocations, but this optimization also implies that the required stack size vanishes and thus, an even higher number of recursive invocations becomes possible. Only a JVM implementation enforcing an intentional limit on the supported number of recursive invocations, independent from the actually required stack space, could enforce this program to ever terminate.
But note, that in the case of an infinite recursion, there is no guaranty to get a StackOverflowError at all. Theoretically, a JVM having an infinite stack space would be a valid implementation. This implies that a JVM, practically optimizing recursive code to run without requiring additional stack space, would be valid too.
So for a typical implementation like Oracle’s JVM, it is practically impossible for your program to ever report a StackOverflowError. They happen, but are shadowed by your follow-up recursions in the finally block, thus are never reported.
I have done some modification to your code and have done some tests. I still cannot figure out an answer to your question. It is the finally block for sure that causes the whole wearied behavior of the code.
public class SimpleFile {
static int i = 0;
public static void main(String[] args) {
int c = i++;
System.out.println("main" + i);
try {
SimpleFile.main(args);
}
catch (Throwable e) {
System.out.println("Catch" + e);
}
finally {
if (i < 30945) {
System.out.println("finally" + c);
SimpleFile.main(args);
}
}
}
}
And the out put is.. i am only showing the last lines:
main30941
main30942finally30940
main30943finally30927
main30944
main30945
main30946
main30947Catchjava.lang.StackOverflowError
I want to prove that even static methods do get StackOverflowError if called recursively. And since you were catching exception that would never catch an Error.
See Call Main Recursively question for StackOverflowError if main is called recursively
Static methods are permanent, it is not stored in a stack but, in a heap instead. The code code you wrote simply calls the same code over and over from the heap, so it won't throw StackOverFlowError. Also, the string inside System.out.println("main"); is stored in the same location which is permanent. Even though you called the code over and over, the same object of string is used, it won't fill the stack.
I got this explanation from the following link :
http://www.oracle.com/technetwork/java/javase/memleaks-137499.html#gbyuu
3.1.2 Detail Message: PermGen space The detail message PermGen space indicates that the permanent generation is full. The permanent generation is the area of the heap where class and method objects are stored. If an application loads a very large number of classes, then the size of the permanent generation might need to be increased using the -XX:MaxPermSize option.
Interned java.lang.String objects are also stored in the permanent generation. The java.lang.String class maintains a pool of strings. When the intern method is invoked, the method checks the pool to see if an equal string is already in the pool. If there is, then the intern method returns it; otherwise it adds the string to the pool. In more precise terms, the java.lang.String.intern method is used to obtain the canonical representation of the string; the result is a reference to the same class instance that would be returned if that string appeared as a literal. If an application interns a huge number of strings, the permanent generation might need to be increased from its default setting.
When this kind of error occurs, the text String.intern or ClassLoader.defineClass might appear near the top of the stack trace that is printed.
The jmap -permgen command prints statistics for the objects in the permanent generation, including information about internalized String instances.
