I know I'm going out on a limb here, but I just can't seem to understand why can't we just create an instance of the Scanner class twice. I'll add an example just in case.
import java.util.Scanner;
public class Nope
{
public static void main(String[] args)
{
System.out.println("What's your name?");
Scanner scanner = new Scanner(System.in);
String name = scanner.nextLine();
System.out.println("Welcome " + name + "!");
scanner.close();
// Now
System.out.println("where you do live?");
Scanner sc = new Scanner(System.in);
String country = sc.nextLine();
System.out.println("That's a lovely place");
sc.close();
}
}
And I get a runtime error which looks something like this
What's your name?
Kate
Welcome Kate!
Exception in thread "main" where you do live?
java.util.NoSuchElementException: No line found
at java.base/java.util.Scanner.nextLine(Scanner.java:1651)
at Nope.main(Nope.java:17)
I know it doesn't make sense to create a new object again of the same class, encouraging redundancy. But I just think it will clear my mind if I know why, don't you think so too?
What does the machine mean by 'java.util.NoSuchElementException: No line found' and people are saying Scanner ain't cloneable.
PS: I intentionally closed my first scanner and created a new object just to understand the issue.
There are actually two separate things going on here.
You should create one Scanner
per input source. For example, one Scanner
for each distinct input file, one for System.in
, one for each distinct socket input stream.
The reason is (as Chrylis points out) is that various methods of Scanner
read ahead on the scanner's input source. If the characters are not consumed by the operation, they are not put back into the input source. Rather they are buffered by the Scanner
, and kept for the next Scanner
operation to use. So if you have two Scanners trying to read from the same input source, one may steal input intended for the other.
This is the real reason why opening multiple Scanner
objects on System.in
is bad. Not the "redundancy" argument that you proposed. There is nothing fundamentally wrong with a bit of redundancy ... especially if it simplifies the application. But scanners competing for input may result in unexpected behavior / bugs.
The second problem is that when you close()
a Scanner
that also closes the input source.
In your case that means that you are closing System.in
. And then you are creating a second Scanner
to read from the (now closed) System.in
.
When you attempt to us a Scanner
to read from a closed System.in
, that leads to a NoSuchElementException
.
So if you hadn't called close()
on the first Scanner
, your code might have worked, but that would depend on the sequence of operations you made on the first Scanner
.
People are saying
Scanner
ain't cloneable.
They are correct.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With