Recently, I started developing mobile apps and started studying swift and kotlin. Under such circumstances, I first touched on the concept of "Optional type" and wondered "Is there a language that has such a convenient type?", But after careful examination, I found that Java 8 also has Optional type. I knew it now. The following is the JavaDoc for Optional. https://docs.oracle.com/javase/jp/8/docs/api/java/util/Optional.html
A type of variable that can store null (nil in some languages).
In Java, ** primitive types ** such as ʻintandboolean cannot store null (compile error), but ** reference type ** variables such as ʻInteger and String are Since nulls may be stored, you may get a NullPointerException if you don't check null in advance.
The first question I felt as a program beginner.
Since the reference type is also included in
null, there is no need to bother to define the ʻOptional` type, right?
Certainly, neither the Optional type nor the reference type is relevant in the sense of "a type that may be null ". The important thing is that in the case of reference types, you have to check null, and it's easy to neglect it.
If you neglect to check null, you will get a NullPointerException, which is a run-time exception, so in the worst case you may not realize that it will not be a production failure.
String str = getString();//If this returns null
//If you forget the following if statement, it will compile, but you will get a NullPointerException at runtime.
//if(str == null){
// str = "";
//}
return str.length();
On the other hand, when the Optional type is used, the value cannot be retrieved unless a dedicated method is used, so ** must be coded in consideration of the case of null. ** **
In other words, I think the biggest merit is that you don't miss what to do if null enters unintentionally.
Optional<String> opt = Optional.ofNullable(getString());
String str = opt.orElse(""); //Null-aware method to retrieve value from Optional`orElse`It cannot be taken out without using.
return str.length();
Why. I've forgotten it all these days, but it's not important to be safe (check null) when something unexpected happens, and it's not important to do something unexpected. It's more important not to build it (eliminate the cause of the null being returned).
If you compare it with the above code,
String str = getString();//Isn't it bad for getString to return null in the first place?
//The following process should have been described, but getString()Isn't listed in the spec to return null
//if(str == null){
// str = "";
//}
return str.length();
That is the case.
Isn't it straightforward to think that it's safe to check null for the time being, without knowing who (which code) is responsible for considering null?
From experience, the module corresponding to the precedent getString is a prerequisite module made long ago by another vendor, or it is also diverted to other systems that are already in operation, so it is related to the maintenance cost of the contracted project etc. Because of this, it is often treated as a "module that cannot be repaired", and it is overwhelmingly coded according to the situation that "there is no choice but to think realistically" rather than the idea that "it should be as a design". There are many.
The reason why I decided to put together this article is that I am content with the fact that I have no choice but to think realistically recently, and I will implement it simply thinking that it is safe to check null for the time being. Because I felt like it had become.
It is well known that modules that were originally left as an implementation in which null entered due to carelessness of the programmer, or intentionally made null, instead of intentionally making it null. Without, or over time, the inheritance of the content "I intentionally made it null "stops, and the act of judging that" it is impossible to become null in this case" is bad.
The Optional type can force the programmer to consider the case of null, but we must not forget the idea of designing how to handle null. (← Commandments to yourself)
For example, if getString () is a module that may return null, then the return value ofgetString ()should also be Optional.
Optional<String> opt = getString();//Should be explicitly stated to return an Optional type
String str = opt.orElse("");
return str.length();
Alternatively, if it should be guaranteed that getString () does not return null, then thegetString ()internal processing may be modified so that the caller does not use the Optional type.
String str = getString();//If guaranteed to be absolutely non-null
//The following if statement will be dead code, so it is correct not to implement it
//if(str == null){
// str = "";
//}
return str.length();
Even in new languages such as swift and kotlin that can use Optional, this idea should not be forgotten.