Alan Anderson wrote:Am having a little headache trying to understand what you mean...do you want to continually ask for input as long as the entry is empty?
James Boswell wrote:Your problem here is that once you have called the method getInput() from within it, the flow continues where it left off. Also, you check if input is empty and if it is, you print it to console which seems a strange thing to do.
Campbell Ritchie wrote:There is a problem calling nextLine after anything other than nextLine, which you can read about here. That is particularly a problem if you think nextLine reads the next line, because it doesn’t.
I think you are going to have lots of repeated code if you program like that. I suggest you search my posts for “utility class” and you will find lots of utility classes, probably none of them complete. Put them together to create a utility class called KeyboardInput or similar with methods like nextIntFromKeyboard, nextLineFromKeyboardAfterSomethingElse, nextLineFromKeyboardOnItsOwn, etc. You can overload those methods to print different sorts of messages in case of incorrect inputs, and you can ensure incorrect inputs never make their way back to the calling class by using methods like hasNextInt. That might appear time‑consuming, but it will give you a resource you can use many times again.
And welcome to the Ranch
Jan Engstrom wrote:So nextLine is not usable in this case...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Quite right. I am happy about using nextLine() (assuming you use Scanner at all), but, as that old post shows, you have to be very circumspect about nextLine() after a different Scanner method call.Winston Gutkowski wrote: . . . No, I don't think that's what he's saying. . . .
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |