Aborting a program for invalid floating-point input

There are a couple of issues.

• Why is the application pausing for 2 seconds before exiting? Why not just exit straightaway? (And if the answer is that you are running this via Windows 'cmd.exe' then you are better off handling the pausing at that level ...)

• Given that you do need to pause, then you are better of writing a helper method to do something like "print a message, pause, and exit with a non-zero exit code". Then use that in multiple places, as required.

• You should be setting a non-zero exit code when you exit due to a failure. This allows the script or whatever that launched the java app to detect the failure and (maybe) do something about it; e.g. pause so that the user can see the error message ...

• The InterruptedException is not a program error, so printing a stacktrace is probably not appropriate.

Figuring out what to do with an InterruptedException exception is not straightforward. The exception indicates that something (either the user or the application) has interrupted the application, either before or during the sleep.

• In this use-case you are just about to exit anyway, so the best strategy is to ignore it an exit anyway.

• You need to decide what is a sensible thing to do. Some possibilities are:

  • Ignore the interrupt and carry on regardless.

  • Take steps to cause the application to stop what it was doing; e.g. throw a custom unchecked "stop now" exception. (You could also call System.exit() directly, but that can also be a bad thing to do, depending on the nature of the code. For instance, calling System.exit() in a library ... or a webapp ... is a big non-no.)

  • Punt: reinstate the "interrupted" state by calling Thread.currentThread().interrupt() in the exception handler. For instance, you might do this if some enclosing code is checking the "interrupted" flag.

Looking at your specific case of Thread.sleep, and knowing other IO exception throwing methods (close() for example), how about using helpful libraries like Google Guava? See: http://code.google.com/p/guava-libraries/

For the Files example, you can use Closables.closeQuietly(filehandle), which does not throw an exception. See: http://guava-libraries.googlecode.com/svn/trunk/javadoc/index.html

For your sleep example, you could make similar methods (if you really wanted a thread to sleep ~2 seconds), Sleeper.sleepQuietly(2000), etc.

You hit infamous checked exceptions feature in Java. Here is one of the basic articles on this, by Bruce Eckel but you can find more by googling "checked exceptions in Java".

In most cases it's hard to avoid try/catch blocks but all you need to do in most cases is to rethrow the exception without any processing. In my code I am using the following pattern (using Throwables from Google Guava library):

void myMethod() {
  try {
     APIFunction1();
     APIFunction2();
  } catch (Exception e) { throw Throwables.propagate(e); }
}

I consider this the least necessary evil. You can write similar utility yourself, quite easily.

How about :

try {
    double a = Double.parseDouble(secondInput);
}
catch(NumberFormatException nFE) {
    displayNotIntegerErrorAndExit();
}

[...]
private void displayNotIntegerErrorAndExit() {
   System.out.println("The input was not an integer.");
   sleepFor(1997);
   System.exit(0);
}

private void sleepFor(long delayInMs) {
   try {
       Thread.sleep(delayInMs);
   } catch (InterruptedException e) {
       e.printStackTrace();
   }
}

Note: I did not check if it compiles or anything, but that is the way I do it normally. And it makes it easy to see if you are duplicating code (i.e. if you are making 300 sleepFor() methods).

Edit: As an additional point. When handled correctly, the increase in readability and flexibility or the code that comes from exception far outweighs the minor overhead of the exception handling.

Not sure on Java since it is a while since I coded with it but in C#, a try-catch block carries a performance overhead that is best limited. A single block is expensive, and best replaced with conditional evaluation to prevent the exception being thrown in the first place, but using nested blocks is okay for basic home projects but if I had to peer review that code I would push it right back to the source developer and ask them to refactor the codefor optimisation.