0

I have this very simple code snippet:

static String getInput() throws IOException{
  if(in.ready()){
      return in.readLine().trim();
  }
  System.err.println("Please provide more input in order to execute the program.");
  System.exit(0);
  return "";
}

By what I think I know, there is no possible way that the JVM will execute the return statement at the end of the code. But if I comment this line out, java will complain about a missing return statement. Why doesn't the JVM recognize that a System.exit(0) will not allow any other code to execute, but complains about unreachable statements if a return will not allow code to be executed? I think the return statement at the end is redundant and might be confusing to other devs, so why won't java let me get rid of it?

janDro
  • 1,426
  • 2
  • 11
  • 24
  • System.exit(0); is just a method as far as the compiler is concerned and the SecurityManager can prevent it from doing anything. e.g if you call it in an application server you don't want it to kill all the applications. – Peter Lawrey Jan 24 '14 at 15:59

1 Answers1

8

Why doesn't the JVM recognize that a System.exit(0) will not allow any other code to execute, but complains about unreachable statements if a return will not allow code to be executed?

It's not the JVM - it's the compiler. And the compiler doesn't know what library calls will do - it only knows the language rules. (In particular, JLS section 14.21, Unreachable Statements.)

So for example:

public int foo() {
    alwaysThrow();
    // This is required.
    return 10;
}

private static void alwaysThrow() {
    throw new RuntimeException();
}

vs

public int foo() {
    throw new RuntimeException();
    // Error: unreachable statement
    return 10;
}

That simple inlining changes the meaning of the code as far as the compiler's concerned.

This could be "fixed" by having a return type of "never" - to indicate "this method never returns normally - it either hangs or throws an exception" but that's simply not part of the language (and would have its own complications). If you're interested, Eric Lippert has a couple of blog posts on this topic with regard to C# (which is in a similar position): part one, part two.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Agreed. The compiler is simply checking that there are return values on all possible execution paths. It doesn't "known" that System.Exit(0) means that the return "" won't get executed. Why you would actually *do* such a thing (system.exit) is a topic for the reader to consider. – robnick Jan 24 '14 at 15:28
  • @jonSkeet thanks for the precise and quick answer, will accept as soon as possible! – janDro Jan 24 '14 at 15:35
  • @robnick is System.exit bad convention? This particular project was for a crowd not too interested in the stack trace, which is why I chose shorter concise error messages. – janDro Jan 24 '14 at 15:36
  • @janDro: I would catch the exception at the top level and exit there rather than here. It feels like a bad idea of arbitrary methods to call `System.exit`. – Jon Skeet Jan 24 '14 at 15:40