This week's book giveaway is in the XML and Related Technologies forum.
We're giving away four copies of Java XML & JSON and have Jeff Friesen on-line!
See this thread for details.
Win a copy of Java XML & JSON this week in the XML and Related Technologies forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Devaka Cooray
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • salvin francis
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

most efficient way to get number input only  RSS feed

 
Ranch Hand
Posts: 64
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i want number only input saved to a byte (Yes campbell I know)
so if the user enters letters it doesnt crash the program

does try catch have to be used? or is there a better way

also would you do that typically in a do while loop, or just a while loop? does it really matter?

 
Marshal
Posts: 62801
203
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your bootcamp instructor certainly seems to have my number.

I think all the best ways to do keyboard input are high‑level things and they don't return bytes as such. The nearest I can think of is this, which would often be accompanied by this, not that I can remember ever using either of them. You would have to enter a small number. e.g. −123 and call it like this:-
Even System.in.read() return an int. And it declares IOException, which you have to handle somehow. If you go to that link, you will find several other methods with names starting “read”, some of which read into a byte[], which I have never tried. That is useful for reading from a network because information is usually converted into a byte[] to send across networks.
I look on System.in.read() as an example of what a friend calls, “combing your hair with a brick,” so I stick to high‑level methods.
You could try System.in.read() and casts. If you pass a value outwith the range −128...127(inc), the cast will lose information for you, but it will not throw an exception or anything like that. Since chars are unsigned, that means you would lose information from all keystrokes > 127 (=0x7f). You could try a loop:-Maybe other people will think of something, but I can't think of any techniques I would even feed to the cat. I tried the above on JShell and escape didn't stop the input, so you will have to think of a different loop.
 
wayne brandon
Ranch Hand
Posts: 64
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do they teach us this way? its really frustrating...

im really sorry campbell

i actually meant short

i need to save from 900 to about 2400

but this information you just posted is also helpful im sure...sorry again
 
wayne brandon
Ranch Hand
Posts: 64
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
but the general idea is that you have to use a while loop with try and catch right?
 
wayne brandon
Ranch Hand
Posts: 64
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hows this?



anything that can be improved?

also why is it bad to use break?
im sure i saw you say somewhere that you prefer to manipulate booleans? why is this?
 
Saloon Keeper
Posts: 9703
192
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

wayne brandon wrote:why is it bad to use break?
im sure i saw you say somewhere that you prefer to manipulate booleans? why is this?


It isn't. Opinions just differ. Personally I find early returns, breaks, continues and throws MUCH more clear than keeping track of state in boolean variables. The reason is that after such a statement, you can forget about what code paths have lead to that point, and focus on the code paths that managed to pass through. It also helps eliminate the dreadful arrow-pattern, where the entire application is filled with nested if-statements.
 
Campbell Ritchie
Marshal
Posts: 62801
203
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

wayne brandon wrote:hows this? . . . anything that can be improved?

Apart from the fact that ti is totally different from what I thought you meant earlier . . .

Use a loop without if‑elses. Since I come out in spots whenever I see shorts other than below somebody's belly‑button, I shall use proper integers Actually, you will want to put that code in a method in a utility class. If you search my posts you will find parts of such a class to assemble. Then you write:-

also why is it bad to use break?
im sure i saw you say somewhere that you prefer to manipulate booleans? why is this?

Maybe beginners should learn to write loops without multiple return or break, as the theoretically right way, then they will have no difficulty learning multiple return as Stephan suggested, if appropriate.
 
Bartender
Posts: 10720
68
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

wayne brandon wrote:hows this?
anything that can be improved?


Well,
1. You could put your "input" code in a method, so you can reuse it.
2. You could put the method in a separate utility class, for the same reason.
3. If it's in a method, you don't the need the flag.
eg:

And then you can add similar methods for other types to Input as and when you need them.

HIH

Winston
 
Campbell Ritchie
Marshal
Posts: 62801
203
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:. . . PS: It's possible that the complier won't recognise 'for(;;)' and want you to add a statement after the loop. . . .

Why? There is nothing wrong with for (;;)... as long as there really is something after that to form the loop body.
I would give my utility class all static members, and make it uninstantiable with a private constructor.I shall let you try and work out what line 3542 means. The only place where my utility class might throw an exception is line 32 and similar if there are methods for other types' input. You might want a next() method analogous to that in Scanner; that is a rather easier method to implement. You can create other methods similarly, even to distinguish aye and nay as inputs. Search for it; such a discussion does exist on this website. The escape \u2019 is a posh apostrophe. I shall leave you to solve the problem about nextLine(), which can be solved by going through my posts. It isn't in this thread; that only leaves another 62657 to look through. The search button may make that quicker.

[edit]Line number changed.
 
Winston Gutkowski
Bartender
Posts: 10720
68
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:I would give my utility class all static members, and make it uninstantiable with a private constructor.


Yes, I did think of that, but that means that all code in the JVM will use the same Scanner, which could theoretically cause concurrency problems.
Not that it's likely with keyboard input; but if the Scanner has a different source (eg, a file) it could be tricky.

Winston
 
Campbell Ritchie
Marshal
Posts: 62801
203
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would only use that class for keyboard input, where my fingers can be relied upon to be 1000000× slower than the rest of the process. Good point about concurrency; I have tried to make such a class thread‑safe and failed miserably. Maybe somebody else will have ideas about thread‑safety
 
Winston Gutkowski
Bartender
Posts: 10720
68
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:I would only use that class for keyboard input, where my fingers can be relied upon to be 1000000× slower than the rest of the process.


Then wouldn't one option be to create a new Scanner for each input, and run it in a try-with-resources block? Wasteful I know, but since we're dealing with keyboard input, efficiency isn't a high priority.

The only thing I forget is if that closes the underlying stream when its done, which you definitely don't want to do with system.in.

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 9703
192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fie, Campbell!

The solution is simple. Don't use globally accessible state! Wrap user input in a class, and pass an instance of that class around to anything that needs it. That way you can also easily unit-test classes that depend on "user"-input. Here's an example snippet I made using a library I wrote a while ago:



Specifying options for how to ask all the questions makes sure that the prompt is used consistently across the entire application. Concurrency is handled through interactions. A thread that wishes to interact with the prompt must start an interaction, and when done asking questions, must release the interaction. This ensures that multiple interactions don't interleave.

The prompt can also be constructed with readers and writers other than System.in and System.out, so you can use a pre-written conversation, or prompt across a network connection, or something more creative still.

If people are interested, I can make my library available after sprucing the documentation up a bit.
 
Campbell Ritchie
Marshal
Posts: 62801
203
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:. . . create a new Scanner for each input, and run it in a try-with-resources block? . . . The only thing I forget is if that closes the underlying stream when its done, which you definitely don't want to do with system.in.

Winston

It does, alas, close System.in.

Is that the answer to my concurrency problem, Stephan? Please explain more.
 
Stephan van Hulst
Saloon Keeper
Posts: 9703
192
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, making it non-static not necessarily is, because you can still make the class thread-safe. However, letting classes do their own lookup of what stream they're going to use to print to is just bad practice. Instead, inversion of control means that services don't care where they print to, as long as they have something they can use to print with. You inject this dependency on a user prompt into the service's constructor.

The concurrency problem in the user prompt is realized by starting interactions, and releasing the interaction when you're done, the same way you would use a transaction to interact with a database. The interaction instance is like a lock on the prompt.

This doesn't prevent rogue classes from still using System.in and System.out directly, but if you really wanted to, you could replace System.in and System.out with dummy instances.
 
Sheriff
Posts: 12952
216
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What's the use case for making an input class like what y'all are discussing thread safe? Like when would there ever be multiple threads accepting input from the keyboard? What am I missing?
 
Ranch Hand
Posts: 490
10
Android Open BSD Slackware
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yesterday I could hear without attending the second part of the conference, and he mentioned a good way to understand this kind of things is a Digi Comp I made in 1963  http://www.ccapitalia.net/descarga/docs/1963-digi-comp-1-instruction-manual.pdf
 
Winston Gutkowski
Bartender
Posts: 10720
68
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:What's the use case for making an input class like what y'all are discussing thread safe? Like when would there ever be multiple threads accepting input from the keyboard? What am I missing?


Well the reason I gave my (admittedly very simple) Input class a c'tor that takes a Scanner was that I wanted it to be able to work with Streams other that system.in so that, for example, you could supply file-based input to run "simulations" if you want.

However, I suspect Stephan has studied this far more than I have, so I await his pronouncement on how feasibile that is. :-)

Winston
 
Campbell Ritchie
Marshal
Posts: 62801
203
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is conceivable that people would want to run keyboard input from System.in from more than one Thread at once; Not that I have ever tried it.
I am using that class for System.in and nothing else.
 
Winston Gutkowski
Bartender
Posts: 10720
68
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Giovanni Montano wrote:...a good way to understand this kind of things is a Digi Comp I made in 1963

Blimey. Someone who's been around longer than me. Kudos.

Like your quote, BTW. Very Zen. :-)

Winston
 
All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
https://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!