I am having trouble with .hasNext(). It is suppose to read from a file as long as there is text in a file and return false if it has reached the end of the file...
The input file simply has 3 small integers.
When I leave the WHILE LOOP IN MY CODE: I run the program, it compiles and runs with no errors and it seems like an infinite loop at first and then the console just goes blank.
When I comment the while loop out: I run the program, it compiles and runs with no errors and it works perfectly on the first integer but does not go on to the next.
This is why I suspect my problem is caused by .hasNext().
Can someone please explain what might be the problem?
Martin Vajsar wrote:The problem is that you don't consume anything from the scanner inside the while loop. Therefore the hasNext() condition remains valid forever. If you add a call to the next() method into the while loop, your scanner will eventually read everything and the hasNext() condition will return false, terminating the loop.
Hi, Thanks for advice.
I tried using the .next call in the while loop however it still executes the same way. With no errors, only applying the first integer of the input file to the code...
Below is my new code:
hasNext() tells you if there is something there to read. Therefore, use it to test before you read.
You start out with a call to next(), which I guess will fail if your file is empty. So the first time you call hasNext(), you are actually checking to see if there is any input AFTER the input you already read.
You continue in this vein, so that you will detect end of file one line before you actually read it.
What I think you want is "while the file has something in it: [read it, convert it, and write output]. Try a structure like this:
I threw in a line to output the number read from the file, with a preceding newline character, because that makes it easier for me to tell that all lines are processed and what they're doing. the printf() does not make any new lines.
A string is a collection of bytes that follow some rules -- in the case of Java, each character is represented by a two-byte code (well, mostly two bytes), and a bunch of those one after the other is called a string.
In most of our cases, those are probably actually ASCII instead of Unicode; ASCII is one byte per character, fewer bytes but fewer possible characters, and in fact most of our US letters in Unicode are the two-byte equivalents of ASCII one-byte codes. When java reads characters from a file, it uses an encoding rule that tells it whether it is to regard characters as one or two bytes.
If you attempt to read an integer, then presumably you are attempting to read bytes (from a file) that represent an integer in memory. In Java's case, this is 4 bytes in a "2's complement" representation of an integer in binary, allowing for negative numbers by setting the most significant bit to 1, etc.
Without going into more detail (and I'll bet you've had enough already!), the short answer is that this file we are reading has character codes in it, not binary data, and therefore you must read it as character data. If whatever had created the file had put in binary representations of other kinds of data, like int, then the java program could (and would have to) read them that way.