Exception in Java

WBahn

Joined Mar 31, 2012
29,932
That depends on the logic that is being implemented, of which you have given no clue and are forcing us to guess.

Is this a homework question?
 

Thread Starter

arman19940326

Joined Jul 31, 2014
43
N
That depends on the logic that is being implemented, of which you have given no clue and are forcing us to guess.

Is this a homework question?
Hi, No I'm reading a Java tutorial book and this is one of its examples. The book has provided these lines of reasons to answer my original question.
"The next method must be called in the catch block to dispose of the user’s invalid input because the nextInt method leaves the input value in the Scanner’s input stream if an InputMismatchException is thrown. If you omit the statement that calls next, the while loop keeps reading it, throws an exception, and displays an error message in an infinite loop. If you don’t believe me, look at Figure 8-2. I found this error out the hard way. (The only way to make it stop is to close the console window.)"

My problem is that when the next() method is called the program should wait for the user to enter something and then the next line can be executed but when I ran this code it seems that the line after the call of the next() method is run without me entering anything. I'm a bit confused.
 

Thread Starter

arman19940326

Joined Jul 31, 2014
43
That depends on the logic that is being implemented, of which you have given no clue and are forcing us to guess.

Is this a homework question?
And this code tries to get an integer from the user and shows it in the console but when the user enters anything else Java compiler throws an exception. The purpose is to handle this exception by using try-catch blocks.
 

WBahn

Joined Mar 31, 2012
29,932
N

Hi, No I'm reading a Java tutorial book and this is one of its examples. The book has provided these lines of reasons to answer my original question.
"The next method must be called in the catch block to dispose of the user’s invalid input because the nextInt method leaves the input value in the Scanner’s input stream if an InputMismatchException is thrown. If you omit the statement that calls next, the while loop keeps reading it, throws an exception, and displays an error message in an infinite loop. If you don’t believe me, look at Figure 8-2. I found this error out the hard way. (The only way to make it stop is to close the console window.)"

My problem is that when the next() method is called the program should wait for the user to enter something and then the next line can be executed but when I ran this code it seems that the line after the call of the next() method is run without me entering anything. I'm a bit confused.
It is called without you entering anything (more) precisely because of the explanation the book gave you.

When you executed the nextInt() method in the try block and it threw an exception (because you entered "Fred" instead of "42", for instance), the method threw the exception WITHOUT removing "Fred" from the input stream because nextInt() has no idea how you want to handle it. So the catch block calls next(), which simple gets the next token ("Fred") and moves on.

The big problem with this code is that what if there isn't any input to begin with? If that's why nextInt() threw an exception, then the subsequent call to next() is going to throw the same exception which, at this point, will be uncaught.
 

Thread Starter

arman19940326

Joined Jul 31, 2014
43
It is called without you entering anything (more) precisely because of the explanation the book gave you.

When you executed the nextInt() method in the try block and it threw an exception (because you entered "Fred" instead of "42", for instance), the method threw the exception WITHOUT removing "Fred" from the input stream because nextInt() has no idea how you want to handle it. So the catch block calls next(), which simple gets the next token ("Fred") and moves on.

The big problem with this code is that what if there isn't any input to begin with? If that's why nextInt() threw an exception, then the subsequent call to next() is going to throw the same exception which, at this point, will be uncaught.
Thank you! I now have a better understanding. I didn't know about tokens and the fact that next method catches tokens. When user enters something and we want to get it by next method, in fact we created a token that can be caught by an appropriate Scanner class method. Am I right? I mean entering something as an input stream creates a token.
 

joeyd999

Joined Jun 6, 2011
5,220
It is called without you entering anything (more) precisely because of the explanation the book gave you.

When you executed the nextInt() method in the try block and it threw an exception (because you entered "Fred" instead of "42", for instance), the method threw the exception WITHOUT removing "Fred" from the input stream because nextInt() has no idea how you want to handle it. So the catch block calls next(), which simple gets the next token ("Fred") and moves on.

The big problem with this code is that what if there isn't any input to begin with? If that's why nextInt() threw an exception, then the subsequent call to next() is going to throw the same exception which, at this point, will be uncaught.
I think your "big problem" is addressed by the class:

Throws:
InputMismatchException - if the next token does not match the Integer regular expression, or is out of range
NoSuchElementException - if input is exhausted
IllegalStateException - if this scanner is closed
 

joeyd999

Joined Jun 6, 2011
5,220
@WBahn -- it appears that one purpose of the scanner class is ease data entry parsing for console based applications. But upon reading the class def, it seems quite useful for all kinds of tasks -- like parsing a text file of a particular known format. The fact that it supports regular expressions multiplies the usefulness. It's actually pretty neat. It reminds me of some stuff I just did recently in .asm...
 

WBahn

Joined Mar 31, 2012
29,932
How is it addressed by that? The code that is presented appears (and it only appears because the desired behavior has not been provided) to want to simply skip input values that are not of the desired format. If there is no next token, then nextInt() will either block or throw a "NoSuchElementException" instead of the "InputMismatchException" that the catch block is intended to handle. Is the desired behavior that it will have an unhandled exception in that case? Or is the intent that the type of Scanner object created will block? I don't know, because we can only guess at what the desired behavior is.

Another potential problem for the compiler is that it may not be discernible that the GetAnInteger() method will always actually return an integer (or throw an unhandled exception).
 

WBahn

Joined Mar 31, 2012
29,932
@WBahn -- it appears that one purpose of the scanner class is ease data entry parsing for console based applications. But upon reading the class def, it seems quite useful for all kinds of tasks -- like parsing a text file of a particular known format. The fact that it supports regular expressions multiplies the usefulness. It's actually pretty neat. It reminds me of some stuff I just did recently in .asm...
It's also very useful for parsing String objects.

There are a number of subtleties in its behavior, particularly where blocking versus nonblocking behavior is concerned since how you want it to behave when reading from a file is often quite different from how you want it to behave when reading from the console from a live operator (as opposed to a console stream that has simply been redirected to it from the output of another process).

But you are correct, it is a very useful and powerful class.
 

WBahn

Joined Mar 31, 2012
29,932
I think your "big problem" is addressed by the class:
I think I see what you are getting at here, namely that under the two cases I initially referred to that nextInt() will throw two different kinds of exceptions and the exception handler only catches one of them. That is a very valid observation.
 

joeyd999

Joined Jun 6, 2011
5,220
How is it addressed by that? The code that is presented appears (and it only appears because the desired behavior has not been provided) to want to simply skip input values that are not of the desired format. If there is no next token, then nextInt() will either block or throw a "NoSuchElementException" instead of the "InputMismatchException" that the catch block is intended to handle. Is the desired behavior that it will have an unhandled exception in that case? Or is the intent that the type of Scanner object created will block? I don't know, because we can only guess at what the desired behavior is.

Another potential problem for the compiler is that it may not be discernible that the GetAnInteger() method will always actually return an integer (or throw an unhandled exception).
I meant, there is an exception thrown for the particular case you mentioned. Not that the code example utilized it.

I hope OP recognizes the value of studying the actual class definition -- not just the parts the book wants to use. When I come across a new concept while programming (or, anything else for that matter), I try to understand the full concept prior to proceeding. I may not need to know all at that moment, but I can't count how many times such info became invaluably important at some point in the future.
 

WBahn

Joined Mar 31, 2012
29,932
I hope OP recognizes the value of studying the actual class definition -- not just the parts the book wants to use. When I come across a new concept while programming (or, anything else for that matter), I try to understand the full concept prior to proceeding. I may not need to know all at that moment, but I can't count how many times such info became invaluably important at some point in the future.
I agree completely. It is not unusual for me to read the "real deal" from the standard or other authoritative source and for there to be a significant amount of it that sails over my head. But even when that is the case it usually gives me enough additional context to better understand the "for dummies" version and often gets me thinking in a direction that lets me find a better approach altogether.
 

joeyd999

Joined Jun 6, 2011
5,220
I agree completely. It is not unusual for me to read the "real deal" from the standard or other authoritative source and for there to be a significant amount of it that sails over my head. But even when that is the case it usually gives me enough additional context to better understand the "for dummies" version and often gets me thinking in a direction that lets me find a better approach altogether.
Just knowing the reference exists is a major advantage.
 
Top