Why is StackOverflow exception thrown due to recursion when args is null?

[Clemonte Johnstone]

Hi, please could someone kindly explain why this code throws an exception because of StackOverflow/recursion?

   public class _09_Exception_Handling {
       public static void main(String[] args) {
           try {
               main(args);
           } catch (Exception ex) {
               System.out.println("CATCH-");
           }
           System.out.println("OUT");
       }

I understand that there are no parameters from args i.e. it is null so why does it go into multiple iterations?

[Piet Souris]

'args' is not null, String[] may be empty.

But that is not relevant here. The first thing that 'main' does is calling itself, so that after a while you get that SO exception.

[Clemonte Johnstone]

Piet Souris wrote:'args' is not null, String[] may be empty.

But that is not relevant here. The first thing that 'main' does is calling itself, so that after a while you get that SO exception.

Hi. Ok, so why is the exception not caught then?

[Piet Souris]

Sorry for calling it an Exception. It is of course an Error that is being thrown.

[Clemonte Johnstone]

Piet Souris wrote:Sorry for calling it an Exception. It is of course an Error that is being thrown.

But the compiler prints the following which is a contradiction. As you know in the Exception hierarchy Error is on the other side of Exception

Exception in thread "main" java.lang.StackOverflowError

[Mike Simmons]

Yes, there are many places where people say "exception" when it should really be "error" or "throwable".  Even in materials from Sun and Oracle, including some messages from the JVM.  In text written by humans, there's a tendency to mix these up.  In actual Java code however, there's a strict distinction.  So if you want to catch something that's really an Error, you need to say catch Error or catch Throwable.  

Note that many people will say you should never do that, and in production code that's often true, though not never.  But for experimentation for learning purposes, no problem, go ahead and see what happens.

[Tim Holloway]

The root of everything that can cause an immediate and rapid ascent back up the call stack is java.lang.Throwable. Throwable is not normally used directly as an application base class itself but rather via one of the two primary throwable bases: Error or Exception. And, of course, Exception further breaks down between unchecked (RuntimeException) and unchecked Exceptions (everything else).

Note the class name here: It's StackOverflowError, not Exception.

And, while as Mike has said, we tend to think of any throwable abstractly as an "exception", you're trying to catch explicitly class java.lang.Exception and subclasses thereof, not java.lang.Error and and its descendants (including StackOverflowError). Nor, for that matter would your catch clause catch anything that someone might have built directly on java.lang.Throwable that wasn't a java.lang.Exception.