Often I invoke alien methods which might return a null value. In order to avoid simple null checks like
if (myVariable != null) {
// do something
}
I sometimes assign a default value, like this:
myVariable = (myVariable == null) ? defaultValue : myVariable;
This seems a little bit redundant in Ruby for instance, there is the ||= operator
I am not asking for such an operator, but my standard approach with the ternary operator seems a little bit redundant or maybe also confusing?
What better ways are there?
Try this:
if (myVariable == null) {
myVariable = defaultValue;
}
If the alien method maybe return null value, it should note about null return value in method's Java docs. The client uses that alien method must check, but no way, the return value.
The simple way to do this:
retVal = alienMethod();
if (retVal == null) {
retVal = defaultVal;
}
If you still want to avoid checking null value, the method that return the value must be in responsible for return default value. But what is your default value? Depend on your return type, you can create a dummy class to represent your default value instead of returning null value.
There are no better/shorter/nicer ways to do it....
There was talk about introducing a '?' operator for null values in Java 7, but the concept got shifted out of the release.... maybe for Java 8 ?
https://blogs.oracle.com/darcy/entry/project_coin_final_five
http://viralpatel.net/blogs/2009/10/null-safe-type-java-7-nullpointerexception.html
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html
In general, there is no "elegant" way. If the variable is a field of your class, you can do it in the setter or getter. But proper javadocs (which I don't show below!) are important to explain what happens to nulls. e.g.
public void setFoo(Foo foo) {
this.foo = foo != null ? foo : DEFAULT_FOO;
}
public Foo getFoo() {
return foo != null ? foo : DEFAULT_FOO;
}
You can wrap the assigning of a default value into a small utility function and put it in a helper class. For variables of type String, this would look like this:
public static String unNull(String val,String defVal) {
return (val==null ? defVal : val);
}
Then, in your code you can just write
myVariable = unNull(alienMethod(),defaultValue);
Using a static import, you can do without prefixing the static method's name with the class name.
You can also make a generic method to handle this (to template the type of both arguments and the return type), but I'm not sure it would work without an additional parameter of type Class.
There is finally a better way to do it: Optional in Java 8. Instead of
Foo myVariable = bar();
myVariable = (myVariable == null) ? defaultValue : myVariable;
where bar() may return null, now you do
Foo myVariable = Optional.ofNullable(bar()).orElse(defaultValue).get()
Related
In java, we can declare a null class object like this
VideoRecord videoRecord;
After that, we can check if it is null or not
if (videoRecord == null){
videoRecord = new VideoRecord();
}
I am new to Kotlin and I would like to do the same thing in Kotlin. I have tried this code below.
lateinit var videoRecord1:VideoRecord
if (videoRecord1 == null){
videoRecord1 = VideoRecord()
}
But it gives me a warning like the condition videoRecord1 == null is always false. How can I make the same thing in Kotlin?
var videoRecord: VideoRecord? = null
you can initial its variable like this
nullable reference : https://kotlinlang.org/docs/reference/null-safety.html
Depending on what you're trying to achieve, e.g. lazy initialization then this may be more suitable for you than the answer given by andika_kurniawan:
val videoRecord: VideoRecord by lazy { VideoRecord() }
This will lazily initialize videoRecord the first time it is accessed.
The advantage of this way is that you don't have to check for null when accessing videoRecord, because it cannot be null. This simplifies the usage of that variable significantly. Additionally you can mark videoRecord as val, meaning it is final, so it cannot be overwritten.
The example shown by #andika_kurniawan:
var videoRecord: VideoRecord? = null
Has some caveats and disadvantages:
You always have to check that videoRecord is not null (and it gets tedious), see this example:
if (videoRecord != null) {
videoRecord.callAMethod()
}
The above will not work, because videoRecord defined as nullable, so you need to use the !! operator to tell kotlin that you're sure that the variable is not null:
if (videoRecord != null) {
videoRecord!!.callAMethod()
}
You can of course use other idioms, like the null-safe operator ?.
videoRecord?.callAMethod()
Or the already mentioned !! operator (which throws an exception when it is null) but this time without a null check:
videoRecord!!.callAMethod()
You may also use local variables, which simplify the usage (a little bit):
val videoRecord = videoRecord
if (videoRecord != null) {
videoRecord.callAMethod()
}
The variable is not final, so nothing stops you from doing this somewhere in your code:
videoRecord = null
You have to initialize it somewhere, so if you have multiple methods accessing videoRecord you first have to initialize it if it hasn't already been, introducing unnecessary redundancy.
In kotlin, declaration of variable is different from java as kotlin is null safe language. You have to declare variable nullable. Only then its value can be null.
You can declare it as below
var videoRecord: VideoRecord? = null
To access nullable values you have to use !! or ? with variable names.
I wrote this code, and I was wondering if there was a built-in method from spring that does the same thing as this method.
public static String map(String value) {
return value != null && value.isEmpty() ? null : value;
}
I found ObjectUtil, but it didn't have any method that has the same functionality.
I would appreciate any suggestion!
Looking at your code seems you just map the empty string to null instead of avoiding it at all.
public static String map(String value) {
return value != null && value.isEmpty() ? null : value;
}
If value is null it return value so null, if it's empty it returns null again.
If your intent is to avoid null values, you should introduce the NullObject pattern.
On java 8+ use the Optional as it is the same, but natively supported by the language.
As already shown in comments by Jan Schumacher, it helps you to easely filter the value further.
With your function you still need a null check, but using Optional you don't need it anymore and the code is much clearer.
You can even use the #NotNull annotation in the method signature, to help enforce null values to be propagated when not expected.
As you know, java.util.Objects is
This class consists of static utility methods for operating on objects.
One of such methods is Objects.isNull().
My understanding is that Objects.isNull() would remove the chance of accidentally assigning a null value to object by omitting the second =.
However, the API Note states:
This method exists to be used as a Predicate, filter(Objects::isNull)
Would there be any reason/circumstance for which I should use object == null over Objects.isNull() in an if statement?
Should Objects.isNull() be confined to Predicates exclusively?
should use object == null over Objects.isNull() in a if statement?
If you look at the source code of IsNull method,
/* Returns true if the provided reference is null otherwise returns false.*/
public static boolean isNull(Object obj) {
return obj == null;
}
It is the same. There is no difference. So you can use it safely.
Objects.isNull is intended for use within Java 8 lambda filtering.
It's much easier and clearer to write:
.stream().filter(Objects::isNull)
than to write:
.stream().filter(x -> x == null).
Within an if statement, however, either will work. The use of == null is probably easier to read but in the end it will boil down to a style preference.
Look at the source:
public static boolean isNull(Object obj) {
return obj == null;
}
To check for null values, you can use:
Objects.isNull(myObject)
null == myObject // avoids assigning by typo
myObject == null // risk of typo
The fact that Objects.isNull is meant for Predicates does not prevent you from using it as above.
Would there be any reason/circumstance for which I should use object == null over Objects.isNull() in a if statement?
Yes, one reason is to keep the code simple. Within if statement object == null is clear and well known. It can not lead to any misbehavior if for example there is a typo.
My understanding is that Objects.isNull() would remove the chance of accidentally assigning a null value to object by omitting the second =.
If there is an if (object = null) {} with omitted = it will not compile or it will generate warning in case of Boolean object! Actually there is no reason to use Objects.isNull(object) over object == null within if statement. Here are the two variants side by side:
if (object == null) {
}
if (Objects.isNull(object)) {
}
Should Objects.isNull() be confined to Predicates exclusively?
It could be said yes, it is confined to Predicates exclusively, although there is no technical hurdle to use the Objects.isNull() everywhere.
From the public static boolean isNull(Object obj) method's javadoc:
#apiNoteThis method exists to be used as a java.util.function.Predicate, filter(Objects::isNull)
So if you use the method as not a predicate you are actually using a more complex and cumbersome expression compared to the simple object == null.
Here is a snippet to compare the benefit of Objects.isNull(object)
List<String> list = Arrays.asList("a", "b", null, "c", null);
// As ready-made predicate
long countNullsWithPredicate = list.stream().filter(Objects::isNull).count();
// Lambda
long countNullsWithLambda = list.stream().filter(object -> object == null).count();
// Reimplement the Objects::isNull predicate
long countNullsWithAnonymous = list.stream().filter(new Predicate<Object>() {
#Override
public boolean test(Object obj) {
return obj == null;
}
}).count();
Semantically there is no difference but for readability I prefer the following over whatever == null:
import static java.util.Objects.isNull;
// Other stuff...
if(isNull(whatever)) {
}
I have a class like this.
public class SomeClass {
private Optional<String> testString;
public SomeClass() {
populateFields();
}
public Optional<String> getTestString() {
return testString;
}
private void populateFields() {
if(//something is going false here){
testString = functionThatReturnsOptionalString();
}
}
}
Now instanceOfSomeClass.getTestString() returns null. Isn't Optional always supposed to contain a non-null value or be empty? I am trying or avoid isNull() and just use isEmpty() in my caller.
If I put a breakpoint on the first line of populateFields() and check the value in testString at that time, it shows the value as null. Meaning the default value for this field(before being assigned anything) is null.
Please shed light on this situation; and maybe the correct usage of Optional?
An Optional always contains a non-null value or is empty, yes, but you don't have an Optional, you have a reference of type Optional pointing to null. You need to initialize testString, e.g. to Optional.empty().
Optional isn't magic, it's an object like any other, and the Optional reference itself can be null. It's the contents of the Optional that can't be null.
From the oracle documentation for the Optional type :
A container object which may or may not contain a non-null value.
So, yes it will return null if the variable is set to null.
More info here
I always like to store the internal fields of the class as their actual values, and use return Optional.ofNullable(theField) in the getter method. This ensures that the method will always return some type of optional. In other words, you never run into the situation where your method which is supposed to return an optional is returning null.
So in your case:
private String testString;
...
public Optional<String> getTestString() {
return Optional.ofNullable(testString);
}
In additional to the 'never returning null' benefit, this approach should also be more behaved when using things like Gson to marshal instances of your class into a format like JSON. I haven't tried Gson with Java 8 optionals, but with Guava optionals they don't serialize very nicely into JSON without a type adapter. If you're storing the raw value and then wrapping them with Optionals at your getter methods, they serialize into JSON in just the manner you would expect.
From the Java documentation:
A container object which may or may not contain a non-null value. If a
value is present, isPresent() will return true and get() will return
the value.
Although the constructor of YourClass does not instantiate your Optional class which is why it is null.
public SomeClass() {
this.testString = Optional.empty();
}
source: http://docs.oracle.com/javase/8/docs/api/java/util/Optional.html
That's because your first need an object of class Optional<String> and the code has only a reference of type Optional<String>, which is null as long as you don't initialize it. Declare (and initialize) testString with an empty/absent value in the following way:
private Optional<String> testString= Optional<String>.empty() ;
Or using type inference:
private Optional<String> testString= Optional.empty<>() ;
private Optional testString= Optional.empty<String>() ;
Now you have an actual Optional object attached to reference testString instead of null. Java 10 would allow the even shorter
private var testString= Optional.empty<String>() ;
If you already have a String value to start with (let's call it originalString), there are 3 main options:
Initialize testString with private Optional<String> testString= Optional.of(originalString) ; (which would produce a NullPointerException if originalString is null)
Use Optional.ofNullable(originalString) instead, which produces an empty/absent Optional if originalString is null.
Refer to originalString in method getTestString directly through one of the two previous methods (return Optional.ofNullable(originalString) ;, for example). No need for a testString member. I actually do not generally recommend this practice.
Bottom line, while an actual Optional object can not contain a null value, a reference to an Optional definitely can (especially when not initialized). As a rule of thumb, Optional references should always be initialized with Optional.empty() if not an actual "present"/"non-empty" value.
I have a result object like:
public class ActionResult {
int ...
String ...
Boolean ..
}
And my method:
public ActionResult getAbc(..) {
String string1;
Boolean bool1;
int int1;
string1 = someDao.get(p1);
if(string1 != null) {
bool1 = someDao.getB(string1);
}
}
Now I want to replace this with my ActionResult object, but finding it looks messy and I have to convert the values, but the value may be null and my set calls will fail then correct?
Example:
if(result.getString1() != null) {
result.setBool1( someDao.getB1(result.getString1()) );
}
The problem is, the result of calling getB1 actually returns a string (3rd party lib I can't change that), that I then have to cast to a boolean.
result.setBool1( Boolean.parseBoolean( someDao.getB1(result.getString1()) ) );
Also, the call to getB1 may return null, now what?
It just seems the code looks very messy and hard to read don't you think?
Two ways to treat null:
Consider null as either true or false depend on your problem domain;
leave null as null, which simply undetermined.
You have to decide what happens when your library returns null One pattern if it is a string is to compare it with true.
"true".equalsCaseIgnore(valueWhichCouldBeNull)
like equals, if the value is null, it returns false. You have to decide if this is correct. Should it be true or throw an exception (which what exception should it be?)