Thread: Confirming if a User Input is an Integer/Double

I have been writing a simple calculator program (no GUI) and one thing I have noticed is that while the calculator is in a calculation mode (adding/subtracting/etc.), if the user inputs a word or some invalid symbol (usually characters), the program just throws an exception and ends.

I fully understand why. The input line in the method is written as:

[CODE]
String userInput = user.getUserInput(" ");
double addNum = Double.parseDouble(userInput);
[/CODE]

If I am correct, the JVM is trying to parse some input (say "cat") to a double and can't do that. So it throws the exception:

Exception in thread "main" java.lang.NumberFormatException: For input string: "c
at"
        at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:12
22)
        at java.lang.Double.parseDouble(Double.java:510)
        at Arithmetic.Add(Arithmetic.java:5)
        at SimpleCalc.main(SimpleCalc.java:13)

All I am looking to do is create an error guard that will detect if the user inputs a String that is not numeric and will say "Your input was invalid."

I was thinking of using an IF statement to check if it was a integer/double but ran into two problems:

1. I don't exactly know how to do that...
2. The problem seems to occur when the parsing attempt is made on the input String. So the if statement would have to come before the parse. I'm not sure how to go about saying "All numeric strings"

I have checked the API but I am rather new to Java so I don't understand all of it... forgive me if I missed something.

Any help you can offer is appreciated. Thanks for your time!

As KevinWorkman says, the recommended way to deal with input that can't be processed ('exceptional' input) is to catch the exception and display your error message there. That's pretty much what Java exceptions are there for.

The best way to use exceptions in your code is to try to keep the whole body of the method code within a single 'try' block, and catch any exceptions at the end of the method. It isn't always possible, but the idea is that you can write the body of your code without worrying serious errors, which makes the code simpler, clearer, and more robust. In cases where you need a 'catch' in the middle of the method code, it's worth considering putting the bit of code that may throw that exception into a separate method along with that catch... it's a judgement call - a question of deciding the best way to keep things clear and simple:

void method(..) {
   // declare variables
   ...
   try {
      // body of method
      ...
   }
   // where possible, handle exceptions at end
   catch(Exception1 e1) {
      ...
   }
   catch(Exception2 e2) {
      ...
   }
}

If I understand you correctly you can do this:

public void boo {
    try {
        doo();
        foo();
        goo();
    } catch (Exception e) {
        // do something
    }
}
 
public void doo() throws Exception {
    //code
    // line that might throw exception
    //code
}
 
public void foo() throws Exception {
    //code
    // line that might throw exception
    //code
 
}
 
public void goo() throws Exception {
    //code
    // line that might throw exception
    //code
}

However, with variables it is recommended that you declare them in the smallest possible scope. You should do the same with try/catch statements. By that I mean if you have 20,000 lines of code and only one of them can throw an exception then put the try around that one line not the whole lot. So the above might be:

public void boo {
    doo();
    foo();
    goo();
}
 
public void doo() {
    //code
    try {
        // line that might throw exception
    }
    //code
}
 
public void foo() {
    //code
    try {
        // line that might throw exception
    }
    //code
}
 
public void goo() {
    //code
    try {
        // line that might throw exception
    }
    //code
}

But it does depend upon the situation. It might make perfect sense for those methods to throw the exception back to the calling method, especially if you do not want the code after the exception to be executed.

I remember when we first did any IO at Uni the first thing that the lecturer showed us was to add throws Exception to the main method. This was since we had not covered exceptions yet and we were just concentrating on IO. Now I would never do that. I will always handle the exception at the appropriate point in the code.

Originally Posted by Junky

However, with variables it is recommended that you declare them in the smallest possible scope. You should do the same with try/catch statements. By that I mean if you have 20,000 lines of code and only one of them can throw an exception then put the try around that one line not the whole lot.

Having said that, methods should be kept as short as possible (i.e. not 20,000 lines!), and a big advantage of exceptions is that they allow messy error handling to be removed from the body of the code, so in practice, you might want the try/catch to surround the block of code that might throw the exception, rather than the single line (I'm assuming the try/catch isn't being positioned just to indicate an exception-throwing call!). Of course, there are trivial exceptions (ha!) to the guideline, like using Thread.sleep(), where, in the absence of an interrupting thread, it's common to put the try..catch in the body of the code, because it's typically very small & self-contained, with a one-line try block and an empty or one liner catch. But I have seen even this put into a separate sleep() method (particularly when the sleep time is parameterized).