• 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
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Missing return statement when it's there

 
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,

I am new to Java and am having difficulty understanding why the compiler is telling me that the following two methods are missing return statements. There is a return statement in each if...else statement (except for the last one, which is instructed to skip using a "continue" statement). So why is the compiler telling me that the methods are missing return statements?

FYI, these methods are part of a code that is meant to convert a string of multiple numeric values into an array of integers.


 
Saloon Keeper
Posts: 5919
152
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The compiler isn't as smart as you :-) If the return statements are hidden in the midst of "if" statements, it's not clear during a static compilation that one will ever be executed.

(The indexOf method looks fishy, by the way. It'll never go beyond index 0, because it returns no matter what.)

In the second method it's even less clear that a return will be executed before execution reaches the end of the method. What happens if "continue" is executed at the end of the loop?
 
Marshal
Posts: 66637
251
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

Please single‑space your code. Only use empty lines to separate successive methods or other logical divisions of the code. Also make sure to indent your code correctly; maybe you didn't realise you were returning fro mthe first index regardless is that you haven't got your {} aligned properly. As Tim is telling you, there is something wrong about creating an 11‑element array inside the loop, one for every run of the loop. Of course when you try to assign to its index 11, you will have other problems. Remind yourself of the syntax for arrays in the Java™ Tutorials.
Only use // comments for something short, otherwise you get your lines too long. If you need long comments use /* comments */ on their own lines.
Avoid == false and == true, which are poor style and error‑prone. What if you write = by mistake? Now you have two errors for the price of one!
Never if (b == true) ...
Always if (b) ...
Never if (b == false) ...
Always if (!b) ...
 
Rancher
Posts: 3404
33
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:The compiler isn't as smart as you :-) If the return statements are hidden in the midst of "if" statements, it's not clear during a static compilation that one will ever be executed.


Well... the compiler can follow that.  The problem is, any time you have a return inside an if statement, it's only guaranteed to return if there's a return in the if and in the else.  And if there's no else, then there's no guarantee of a return.

In that first method, there is a return in the if, and in the else.  That's fine.  But the real problem is, the whole thing is inside a for statement.  And as far as the compiler is concerned, that for statement is not guaranteed to execute even once.  What if the array length is zero?  Then there's no return.  Even if you can prove to yourself that a for statement will execute at least once... the compiler will always assume that a for loop, or while loop, may not execute at all.  And therefore returns in the loop are not guaranteed to execute.

Tim Moores wrote:(The indexOf method looks fishy, by the way. It'll never go beyond index 0, because it returns no matter what.)



Agreed, this is another problem.

Tim Moores wrote:In the second method it's even less clear that a return will be executed before execution reaches the end of the method. What happens if "continue" is executed at the end of the loop?


Here too, the real problem is that the whole thing is in a while loop, which may never execute.  So we need a return after the while, to ensure there's a return.
 
Andre Samuel
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim, Campbell, and Mike,

Thanks so much for all three of your comments! I really appreciate the time you took to answer.

I've modified my two methods following the suggestions and guidelines you suggested. I noticed how off I was while doing that. I'm posting them below again. Now, the only error I am given by the compiler is that in method scanStringToIntArray, the compiler is telling me that input.hasNext() = true is an "unexpected type" (a variable is required but a value is found). Following Campbell Ritchie's advice, I tried to assign the value of "true" to "input.hasNext() so as not to write "while (input.hasNext() == true)" in the subsequent while statement.

From what I read, the hasNext() method of class Scanner checks the input and returns "true" if it has another non-whitespace character.  Would I be wrong to just omit assigning the value of true to hasNext() at the start of the method, and going with "while (input.hasNext() == true) in the while statement? This is against what Campbell said but it allows the program to compile. Will it cause problems later somehow?

Thanks to all who read and answer!


 
Andre Samuel
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I forgot to mention that, in response to what Mike Simmons wrote, the two methods are part of a class where intArray is defined as having 10 elements. So the methods will know what intArray.length is.

Thanks, Mike, for your detailed response! It helped a lot and I feel like I've learned something :-)
 
Bartender
Posts: 715
10
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are you trying to do with line 12?
is calling a method of Scanner; you cannot assign a value to it.
Line 16 should just be since the previous line guarantees that input.hasNext() is true.
 
Saloon Keeper
Posts: 6469
61
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hasNext() returns a value, it is not a variable that you can set.
 
Campbell Ritchie
Marshal
Posts: 66637
251
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Andre Samuel wrote:. . . Thanks so much

That's a pleasure

. . . while (input.hasNext() == true) . . . it allows the program to compile. . . .

Carey has already explained about where you are using = true. I don't remember seeing that problem before

Actually, there is another error only mentioned briefly. If you reduce the loop to while (input.hasNext()) ..., you will create an infinite loop because the keyboard implicitly always has a next input. Unless you close the input stream, but that is a different kind of mistake. Change the loop to something like while (input.hasNext()) ... while (input.hasNextInt()) .... No, that won't work; you are trying to fill an array but you aren't incrementing the index, so you will end up putting repeated numbers into the same array element. I suggest you iterate the array in the usual fashion, forgetting about hasNextInt() and make sure to put ints on the keyboard. Yes, that does take away the type‑safety of checking whether you have an int, but at least you will fill your array most of the time.

[edit]Spelling correction in HTML tag and change one instance of hasNext to hasNextInt.
 
Andre Samuel
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to Carey, Campbell, and Fred for your answers.


Campbell, I don't understand why the "... keyboard implicitly always has a next input". I thought that the hasNext() method checks if the scanner has another token in its input. Wouldn't it return false if there was no other token?

Good point about incrementing the index of the array I'm populating! I hadn't realized that I left that Oh So Important code out. You were right, the way it was written, I would put the repeated numbers into the same array element.

Thanks to all!
 
Campbell Ritchie
Marshal
Posts: 66637
251
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Andre Samuel wrote:. . .I don't understand why the "... keyboard implicitly always has a next input". . . .

As long as the standard input stream, called System.in, is still connected correctly, the system assumes you are going to give it more input. The keyboard is still connected. Don't try to close or disconnect System.in because that will give you new problems later on.

Thanks to all!

That's a pleasure
 
Normally trees don't drive trucks. Does this tiny ad have a license?
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!