0

In a game I'm building, the user is given some options from which they can choose by pressing a number. A switch statement then runs the relevant method. One of the options is to exit the game, which I do by running System.exit(0). I was wondering, if the break after the exit is still useful, and if so, why? And is there a difference if the exit is the last option in the switch statement, or not?

Code goes as follows:

switch(choice) {
    case 1: getEntityOverview();
        break;
    case 2: worldMap.PrintMap();
        break;
    case 3: moveAllOnInput();
        break;
    case 4:
        System.out.println("You are exiting the game, "
            + "thanks for playing!");
        System.exit(0);
        break;
}
Bram Vanroy
  • 27,032
  • 24
  • 137
  • 239
  • No, it's not necessary. Although—personally—I couldn't remove it due to my coding OCD. – MeetTitan Dec 12 '15 at 09:46
  • Would put break as well / preferably not use `System.exit()` in the first place because regular flow control can do the same in a cleaner / more expected / symmetrical way. It's just a regular method (which happens to kill the program) and I would treat it that way when it comes to `switch` etc. – zapl Dec 12 '15 at 10:23

2 Answers2

0

A break prevents a 'fall through' to the next case item. The break is not required here for two reasons:

  • The option in question is the last item in the switch statement so there is nothing to fall through to
  • Even if there was another item below, it will never 'fall through' anyway, as System.exit() does not return as it terminates the application (+/- various hooks)

Perhaps the question means 'does System.exit() ever return?' (in which case if it were not the last item in a switch statement, a break might be required).

According to the documentation:

[System.exit()] Terminates the currently running Java Virtual Machine. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination. This method calls the exit method in class Runtime. This method never returns normally.

The call System.exit(n) is effectively equivalent to the call: Runtime.getRuntime().exit(n)

I don't much like that 'normally'. Runtime.exit has the same 'normally'. I suspect this is however a reference to the fact they can throw an exception, in which case the absence of a break is not an issue. Jon Skeet does not appear to be concerned about it here.

That said, there is nothing to prevent you putting the break statement there. Indeed it may be a good plan in case someone adds another item after, then someone else swaps System.exit() for something that might return, e.g. a call to something saying 'Are you sure you want to quit'?

Community
  • 1
  • 1
abligh
  • 24,573
  • 4
  • 47
  • 84
0

No, you don't need this break statement.

From the javadoc of class System :

public static void exit(int status) Terminates the currently running Java Virtual Machine.

This ends the execution of your application, your program exits, and no further instruction will be executed, unless you registered a Shutdown Hook.

Even a finally block won't get executed.

Hence, the case position where you put System.exit, will make no difference.

Arnaud
  • 17,229
  • 3
  • 31
  • 44
  • I'm unsure how I'd see a `finally` block inside a `switch` statement. I've seen it a lot in `try/catch` but never in `switch`. Could you point me to a resource that mentions this? – Bram Vanroy Dec 13 '15 at 12:57
  • 1
    Oh well, I was just stating that System.exit does bypass many things, even "final" things. Sure, without a "try" , you never get a finally, so it wasn't relevant to your special case :) – Arnaud Dec 13 '15 at 13:00