• Post Reply Bookmark Topic Watch Topic
  • New Topic

What does return "" mean in this context?  RSS feed

 
Mark Richardson
Ranch Hand
Posts: 108
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
consider this code:



I sort of understand that the dateTimeToShortString method here takes in a date. Then we check to see if the date is null, if it is, on the third line, we have return"";
What does the return ""; do exactly?

Also, I don't mind a lengthy explanation, and in fact, I prefer lengthy explanations and answers which lend to discussion. Thank you!
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark Richardson wrote:
What does the return ""; do exactly?


It returns a zero length (a.k.a. blank) string.

Henry
 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark Richardson wrote:Also, I don't mind a lengthy explanation, and in fact, I prefer lengthy explanations and answers which lend to discussion. Thank you!

Cue me... (I'm somewhat of a long-winded replier)

Returning "" here is a way to say something like "Meh, you didn't give me a date that I could turn into a String so here's a String that represents nothing!"  This is probably better than returning null.  Returning null will cause some ripple effects in the rest of the code in that now you have to guard against a NullPointerException when using the result of this method. Returning an actual String object (the literal "" is a String object) allows your client code to not worry about nulls and having to do this kind of check:

The check for null is necessary if the dateTimeToShortString() method could possibly return null. Checking for null before calling shortDate.equals() avoids having a NullPointerException being thrown in your face.

On the other hand, you wouldn't need that null check if dateTimeToShortString() was guaranteed to return a String object, even if it was just an empty string object, "".

I'll let you digest all that for now. If you have more questions, I still have more wind.
 
Tim Holloway
Saloon Keeper
Posts: 18789
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Helpful hint:

"".isEmpty() returns true.

Also, on web pages, the Expression Language, like so:

 
fred rosenberger
lowercase baba
Bartender
Posts: 12562
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your method declaration says "this method will ALWAYS return a string".  So, apart from serious disasters that crash the JVM, the method must return a String.

Now, sometimes, there is no "logical" string to return - what do you do? you return a string that is empty. 
 
Tim Holloway
Saloon Keeper
Posts: 18789
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
fred rosenberger wrote:Your method declaration says "this method will ALWAYS return a string".  So, apart from serious disasters that crash the JVM, the method must return a String.


Except that in Java, a null object can be returned for any method that returns a class object and it's perfectly valid syntactically.

That's the difference between a contract that the language enforces and one enforced by consent.

Many older or scripted languages (Python or JavaScript, for example) can semantically accept the return of anything. Any contracts are strictly consensual.

Java can semantically accept the return of an object of class String or its subclasses (except that String is a final class, so you cannot subclass it), or it can semantically accept the return of null. Returning an integer, an array, or a java.sql.Resultset would result in a compiler error. The contract is mandatory for String and consensual for null.

Some languages are even more semantically obsessive. For example, in Ada, you could restrict a function to only returning an integral value from 7 to 21, inclusive. Failure to do so syntactically (at compile-time) would result in a compilation error. Failure to do so semantically (computing a value outside that range and returning it at run time) would result in a runtime exception.
 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
fred rosenberger wrote:Your method declaration says "this method will ALWAYS return a string".

Well, not necessarily. There is no convention that I know of in Java that says that declaring an object reference return type like String means "This is ALWAYS going to return a String".  Kotlin, another JVM language, introduced the idea of Null Safety as part of the language but the closest thing that I can think of in Java is the Optional type introduced in Java 8.

To get additional perspectives on the decision of whether or not to return null from a method, see this discussion on StackOverflow: http://stackoverflow.com/questions/1626597/should-functions-return-null-or-an-empty-object
 
fred rosenberger
lowercase baba
Bartender
Posts: 12562
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The method delcaration in the OP is:



We have to return something regardless of the execution path.  So there has to be a "return <something>". 

Perhaps I should have said "You have to return something the jvm thinks might be a String, such as a String or a Null Object", but this is the beginners forum.

OR, i have a fundamental misunderstanding of the language.

OR the language has evolved so much in the ten years since I've used it that I wouldn't recognize it any more (and I actually think this is true).

 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@fred: I think the point of contention was "ALWAYS return a String" -- as we know, null is not a String.

Even though this is the beginner's forum, I don't think we should underestimate any OP's capacity to understand certain nuances. I think it's better to err on the side of being precise (but at the same time try to keep things concise) and let OP's responses determine where we need to adjust the discussion to their current capacity to understand.

So, I don't think it's a matter of you having a fundamental misunderstanding of anything; it was just an imprecise statement that implied that declaring a String return type means that your method implementation is obligated to always return an actual String object. There are no such semantics built in to the Java Language. The null value is assignment-compatible with any reference type variable in Java. Java itself has no opinion one way or another if you actually return null or not.

The semantics that required an actual String object to always be returned are semantics that have to be baked in to the design. It's also a good practice to document those semantics in the JavaDocs for that method.
 
Tim Holloway
Saloon Keeper
Posts: 18789
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You probably won't see "or returns null" in JavaDocs. It's such a basic consideration that it's more likely to be documented in the language reference itself.
 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:You probably won't see "or returns null" in JavaDocs. It's such a basic consideration that it's more likely to be documented in the language reference itself.

Actually, "returns null if..." is not that uncommon in the Standard API JavaDocs nor are they likely to raise any eyebrows:

https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#get-java.lang.Object-
https://docs.oracle.com/javase/8/docs/api/java/util/Queue.html#peek--
https://docs.oracle.com/javase/8/docs/api/java/util/Queue.html#poll--

Sometimes it's not so surprising when a method returns null but sometimes it is. You just shouldn't go one way or the other without thinking about the semantics carefully first.
 
Tim Holloway
Saloon Keeper
Posts: 18789
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, actually, I make it a point of always explicitly mentioning if a method returns null in my own JavaDoc comments.

I just don't trust other people to do so.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!