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!
Mark Richardson wrote:
What does the return ""; do exactly?
It returns a zero length (a.k.a. blank) string.
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.
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.
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.
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
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).
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 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:
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.