• Post Reply Bookmark Topic Watch Topic
  • New Topic

Help needed with NoSuchElement exception when using StringTokenizer  RSS feed

 
Erandika Withanage
Greenhorn
Posts: 14
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am writing a code that involves reading two space separated integers from standard input.

I used a BufferedReader and StringTokenizer for this.

My code is as follows.




And this throws an Exception as follows for the line

Exception in thread "main" java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(Unknown Source)
at le.main(le.java:20)

I really can't figure out what I'm doing wrong. Can someone help me put please???
 
John Jai
Rancher
Posts: 1776
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
StringTokenizer has a hasMoreTokens() method to check if it has more tokens. You can use that before calling on the nextToken() method.
 
Erandika Withanage
Greenhorn
Posts: 14
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The declared variables are already given, so is there need for a hasmoreTokens()?

I tried this code with split() too and it doesn't work:s.
 
Stuart A. Burkett
Ranch Hand
Posts: 679
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We'd have to see what was in the file you are reading to tell you what the exact problem is, but at some point you are trying to read more tokens than actually exist.
Try putting some print statements in the code to show what st.nextToken is actually returning and comparing this to what you were expecting
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You don't really have to tokenize your input if the two numbers are separated by space(s). As long as you don't quote the command line argument, the two string-numbers should already be in separate elements of the args array. All you have to do now is is iterate through args and convert each String to an Integer. See Integer.valueOf(String)

Edit: Sorry, I just looked at your listing again and realized I missed "from Standard Input". I would suggest that you first break down your problem into smaller pieces.

1. Read from Standard Input, put it in a String
2. Take that String and tokenize it - put each token in an array
3. Iterate through the array and convert each element to Integer, if possible
4. Display results

Each of the above steps can be a method call that returns something that the next step will use as its input. What I'm trying to say is that your program, as small as it is, is way too complicated than it needs to be and all the clutter is getting you confused. By organizing your program a little better and breaking down the problem into smaller chunks, you will have a better chance at seeing through the code and finding out what you're doing wrong.
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Erandika Gun wrote:. . . I used a BufferedReader and StringTokenizer for this. . . .
Why? A tokenizer is legacy code, which you ought not to use in new code. Why are you not using something like Scanner instead, which will find the next int directly.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote: Why are you not using something like Scanner instead


Aw, shucks. That'll take all the fun out of reading from an input stream! You youngsters these days, with all your nice little gadgets to make life easier. I remember back in the day when we had to use Vectors ... (waxing nostalgic)
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
. . . and I can remember cars which could be started by turning a handle. I never see that sort of car now, unless I go to a motor museum or a vintage car rally (they had one a week ago on the playing-field at the end of our garden).

Yes, I remember having to write my own keyboard input class which had a BufferedReader as a field.
 
Erandika Withanage
Greenhorn
Posts: 14
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Erandika Gun wrote:. . . I used a BufferedReader and StringTokenizer for this. . . .
Why? A tokenizer is legacy code, which you ought not to use in new code. Why are you not using something like Scanner instead, which will find the next int directly.


The Scanner class is slow. I am learning to code through Algorithm contests which requires speed over ease.
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Erandika Gun wrote:. . . I am learning to code through Algorithm contests which requires speed over ease.
Do you really mean “learning”?
 
Erandika Withanage
Greenhorn
Posts: 14
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Erandika Gun wrote:. . . I am learning to code through Algorithm contests which requires speed over ease.
Do you really mean “learning”?


Not actually the basics, but the more salient points.
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no such operator as "><=". This code does not compile.

In general the code is difficult to read. Everything is jammed together with only as much white space as required and no more. NEVER place a closing brace at the end of a line following a semicolon. Doing so makes it very difficult to see the structure of the code. Closing braces belong on a line by themselves. The only exception I can think of is in the instantiation of an anonymous inner class. Please surround the code in a conditional with braces even when there is only one line. Please use class and variable names that convey meaning.

There is no award in Java for the code that uses the fewest keystrokes.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Erandika Gun wrote:I am learning to code through Algorithm contests which requires speed over ease.

So if you win something from advice you get here, will you donate a portion of your winnings to us, to be used towards the upkeep of the site?

Speed over ease, huh... so the idea is to buy now and pay later, too?

Dennis Deems wrote:no award in Java for the code that uses the fewest keystrokes

Unless the code is as clear and succinct as it could possibly be.

 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Deems wrote:There is no such operator as "><=". . . .
There have been errors in the forum software which changes < to ><, so that might not be what was actually posted.
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Erandika Gun wrote: . . . Not actually the basics, but the more salient points.
If you are learning for speed, you are most probably learning it wrong. Also, the best way to get speed out of Java™ is not to code for speed.
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And don’t use the newline character, unless you specifically require LF. Use the %n tag, or get the "line.separator" System property.
Don’t even use LF when you learn how to spell it correctly
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, your bad spelling of LF might be the cause of your problem.
 
Erandika Withanage
Greenhorn
Posts: 14
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:
Erandika Gun wrote:I am learning to code through Algorithm contests which requires speed over ease.

So if you win something from advice you get here, will you donate a portion of your winnings to us, to be used towards the upkeep of the site?

Speed over ease, huh... so the idea is to buy now and pay later, too?



There's no winnings, they are just student competitions:p... But sure, if I ever get so good...;). I'm asking for advice within the competition limits, as its only input/output questions I ask and not strategy.

The code should compile within the given time limit and using the Scanner class slows it down. I read that BufferedReader and StringTokenizer are faster and came up with these problems.

Anyway, thank you all for your kind help.
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Where did it say that buffered readers and tokenizers were quicker? How old was that reference? Have you tested it? How do you know it is accurate?

You need to be circumspect about weird things you find on the net. Here, too, though we usually find errors quite quickly!
 
Erandika Withanage
Greenhorn
Posts: 14
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Where did it say that buffered readers and tokenizers were quicker? How old was that reference? Have you tested it? How do you know it is accurate?

You need to be circumspect about weird things you find on the net. Here, too, though we usually find errors quite quickly!


http://www.cpe.ku.ac.th/~jim/java-io.html

 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That makes interesting reading. I suggest you repeat all those tests for yourself. Speeds might have changed now Java7 is available, but 6u22 is only a couple of years old. That code as seen has a serious deficiency; the readers do not appear to be closed ever.
 
Junilu Lacar
Sheriff
Posts: 11493
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Donald Knuth wrote:Premature optimization is the root of all evil


You are only reading two integers in from user input. Do you really think there's going to be a significant difference that you can actually perceive? If you were doing this in a loop, 10K times, then there might be some concern about a performance difference. But in the real world of software development--and this is where I always go, even when I know I'm talking to students--your biggest cost is not measured in computer processor cycles. Your biggest cost is in development cycles, how long does it take for someone to figure out just what the heck the code is doing, and how the heck am I going to change it so it does something differently (due to changing requirements), how much time am I going to spend testing and retesting, and how much time do I spend trying to find and correct bugs when (and they will) happen? That's the $60M question.

So, the simpler and more straightforward the code, the less costly it is and, in a holistic sense, the faster it is.
 
Campbell Ritchie
Marshal
Posts: 56553
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did you repeat the test? What sort of results did you get? I repeated it myself.

And JL is correct. If you are taking one minute or four seconds to read ten million numbers, that doesn’t matter. The difference between one minute and one week might matter.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!