There are three kinds of actuaries: those who can count, and those who can't.
All things are lawful, but not all things are profitable.
Knute Snortum wrote:Perhaps this wasn't your concern, but this doesn't address the nextLine() after nextInt() problem.
Campbell Ritchie wrote:You are still risking an input mismatch exception. A long time ago, Rob Spoor taught me how you can avoid that exception altogether, with a loop:-That code won't throw an input mismatch exception.
You also would want a private constructor because that utility class should never be instantiated. You can enhance those methods to return only values in a specified range. Other mehods can be written similarly. For nextBoolean(), you will get true from any input matching “true”, but case‑insensitive, but if you write anything else, 1234567890 or Carey (I think) it will interpret that as meaning false.
Campbell Ritchie wrote:You also would want a private constructor because that utility class should never be instantiated.
All things are lawful, but not all things are profitable.
All things are lawful, but not all things are profitable.
Knute Snortum wrote:Perhaps this wasn't your concern, but this doesn't address the nextLine() after nextInt() problem.
You would have one Scanner object per JVM, not one Scanner object per computer, but I don't know more about multiuser systems.Knute Snortum wrote:. . . What about a multiuser system? . . .
Junilu Lacar wrote:Are multiple users and concurrency around standard input really a concern when it comes to this kind of thing? I can't think of any reason it would be. What am I missing?
All things are lawful, but not all things are profitable.
Agree; the only methods of a Scanner that can retun null are the two methods whose names start “find”, Those seek a match for a regex and an Optional<String> might be an appropriate return type of those methods are used. All other methods throw an exception if they don't find the input to be the correct type.Carey Brown wrote:Why "Optional" when there's no chance of returning Optional.empty()?
Liutauras Vilda wrote:Let me put some of my thoughts for the method I chose randomly:
1. Looking to method's name first thing which comes to mind is: hm.. "ok, let me have a look again, what does it do/say?".
1.1 promptBoolean, is it wrapper class going to be returned Boolean or primitive boolean? (as subsequent methods indeed return wrapper). I'd avoid Boolean mentioning at all if name cannot suggest clearly what it is going to be returned. In this case it misleads even due to camel case convention. IDE's are clever enough to show return type of method, so to clutter method names with types information makes it harder to read (personally to myself). When methods say getPerson() - in my head I interpret that: "give me person's blueprint/description/entity, but not its class it is implemented in".
1.2 YN postfix. I'd think it is poor choice. Suggests YN but accepts answers true; false; yes; no; as valid. Again, method name suggests upper cases, while hint upon incorrect input suggests lower cases.
And most of the method names are cluttered in my opinion with the information what the method's signature along with return type should and do provide already.
Campbell Ritchie wrote:
Agree; the only methods of a Scanner that can retun null are the two methods whose names start “find”, Those seek a match for a regex and an Optional<String> might be an appropriate return type of those methods are used. All other methods throw an exception if they don't find the input to be the correct type.Carey Brown wrote:Why "Optional" when there's no chance of returning Optional.empty()?
I am not happy with while (true) ... and exception handling. Rob Spoor taught me the loop I use, ages ago; it completely obviates any risk of an input mismatch exception. The escapes \u201c and \u201d are posh quotes: ””You can do the same sort of thing for yes/no:-Note:1: No need for next() call inside the loop. 2: equalsIgnoreCase() is called twice per loop, but compared to speed of keyboard input, that is probably nothing to worry about. 3: I have missed out the overloading for brevity's sake. 4: I presume everybody is familiar with the strange syntax in line 6.
Carey Brown wrote:Does it return Boolean or primitive boolean? I was following the naming convention suggested by various Scanner methods, such as nextBoolean() which happens to return a primitive boolean. The acceptance of "yes" or "no" as well as "y" or "n" follows a long history of reading other people's code for similar methods. I'll admit that also accepting "true" and "false" was a stretch, and I probably should have left it off.
Should the return type be part of the name? You happen to pick on the YN methods, where "Boolean" in the method name was overkill. I was trying to be consistent with the naming suggested by the Scanner class. Other methods require including the type because otherwise the method name/signature would be the same, e.g. promptDouble(...). In the case of YN I could have left off the return type.
YN posfix is a poor choice? Camel case is sometimes limiting. Would you prefer "promptyn()", or "promptyyesnno?
The hint is also a problem because it shows the expected response in lower case? Should it hint of 'Y' or 'N'? That would suggest that the user add additional keystrokes which is not the case. I can't control the text of the prompt that is passed in, so it might say "Y/N" or "y/n", I wouldn't know. I wouldn't want to require the caller to also pass in an error message as well, but that would be possible. I think this hint suffices.
Carey Brown wrote:I'll admit that also accepting "true" and "false" was a stretch, and I probably should have left it off.
Nothing new to say about it.Yesterday, I wrote:. . . I shall have to have a closer looks the your prompt method later.
Campbell Ritchie wrote:
Nothing new to say about it.Yesterday, I wrote:. . . I shall have to have a closer looks the your prompt method later.
It's this thread. Look at the top of the thread.Deepak Lal wrote:. . . Please share the thread link
Regards,
Deepak Lal
Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.
Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.
Men call me Jim. Women look past me to this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|