When I use getInt() in the following code everything works fine.
The integer entered by the user is printed to the console followed by whatever text the user enters next. But if I try to use the Class3 static getInput() method with the getInt() method I run into problems.
The interger the user enters is printed out but the second print prints an empty String before the user has a chance to enter any text. I assume what is happening is the nextInt() method leaves the end of line character which the nextLine() method immediately reads. My question is why doesn't that happen in the first code? Why does having a second Scanner variable pointing to the System.in change the behavior? Any help would be appreciated!
I remembered and managed to find: in Head First Java, page 112, there is a very nice written utility class for user input.
Didn't compare it with Campbell's written method, might he came up with something better, well, you can compare
Might some ideas you'd find useful to use in your own utility class.
Well, I could guess your opinion based on your previous posts
Campbell Ritchie wrote:I haven't got my Head First with me at the moment, but I shall try to remember to look at it later.
But beside that, OP is going to read not only the string lines, but also an int's, so Head First Java utility class would become dreadful I realized now. Since parsing would be needed for int's.
I think OP is right by writing his own utility class, but still, I can see some useful tips in HFJ version could be looked at.
< -2_147_483_648 .. > 2_147_483_647
I shall leave you to work out what circumstances might lead to an Exception.
To make sure no other classes except nested would create ever an instance.
// I am sure you know why there is a private constructor.
Actually I should be more careful when referring to HFJ, as it is quite old book.
Thanks Campbell for pushing train back on the rails, and sorry Kendall for confusing you - it is hot as in hell in England in these days.
All the methods in one class with each method having a private Scanner variable:
or using a utility class where each method has a private Scanner variable. Note that if you uncomment the final Scanner variable in Class3 and remove the private variables from the methods the newline problem reappears so I don't think it matters if your Scanner variable is static. It looks like any information left in System.in by a Scanner method called by a Scanner variable is discarded when a different Scanner variable calls a Scanner method. Is that true?
Beware: Unless you put locks or other synchronisation on, the keyboard input classes are not thread‑safe.
I am not sure I think the example in HJF page 112 is actually a utility class at all. It does not have the usual features I have come to expect, viz all static members. It also uses the older technique with buffered readers. If you use a Scanner you don't have to worry about Exceptions. If you really want to see an Exception you can write this sort of thingChances are it will print “null”. Don't try to throw such an Exception until you are sure it isn't null; if you do you will suffer a null pointer Exception.
I am not at all convinced you should use multiple Scanners for System.in. Use one, which should be a private static final field in your utility class
Sounds good to me. So should I add the scan.nextLine() to my getInteger() method so I can use it in conjunction with a method which uses nextLine()?
Kendall Ponder wrote: . . . So should I add the scan.nextLine() to my getInteger() method so I can use it in conjunction with a method which uses nextLine()?
Any use of nextLine should be associated with nextLine. If you use nextInt and follow it with nextLine you cannot write this sort of thing:-
Look for this old post (as mentioned earlier), which shows exactly what
Please enter three numbers: 123 456 789
If you pass min greater than max to a method requiring a range, then either i < min or i > max. That means if you are checking for a value in that range, it will continue to ask for new input for ever (or until your hardware wears out and the computer stops working). The correct answer is to add this sort of thing near the beginning of the method… and that is how you are going to get an Exception.
HFJ might be an old book but it is still good.