Answer the question
In order to leave comments, you need to log in
Why is Optional needed and why can't the same actions be performed on null?
I don't think language matters here. I can't figure out why the Optional type was introduced? What prevented everything from being done over null too?
ArrayList<Integer> numbers = new ArrayList<Integer>();
Optional<Integer> min = numbers.stream().min(Integer::compare);
if(min.isPresent()){
System.out.println(min.get());
}
Answer the question
In order to leave comments, you need to log in
You can check the reference for null anyway, without any additional methods and entities. Optional here explicitly says that the result of the method may exist (value) or not exist (null) and does not allow you to get a value without making a choice how to handle the situation with its absence. In addition to the usual get(), there are also getOrElse() methods that allow you to specify a default value, getOrNull().
It can also be convenient to first perform a chain of transformations on Optional using the map() method, and at the end get the value in any convenient way and then work with a "pure" object of the expected type.
In kotline (since the language is not fundamental), nullable types come to the rescue with the fight against NPE. Each class generates two types, for example for the Person class it would be Person and Person?. Method signatures can explicitly specify which types are valid. If Person?, then the compiler will force you to handle the null case. Also, you will not be able to return null from the method if you declared the Person type as a result. The program just won't compile. All to ensure that null does not come from unexpected places, is processed and does not drop the program.
The concept of optionals is not new and simple as a bath leaf. It's just an enum:
(You can see the full implementation here )
enum Optional<Wrapped>: ExpressibleByNilLiteral {
// The compiler has special knowledge of Optional<Wrapped>, including the fact
// that it is an `enum` with cases named `none` and `some`.
/// The absence of a value.
///
/// In code, the absence of a value is typically written using the `nil`
/// literal rather than the explicit `.none` enumeration case.
case none
/// The presence of a value, stored as `Wrapped`.
case some(Wrapped)
/// Creates an instance that stores the given value.
@_transparent
public init(_ some: Wrapped) { self = .some(some) }
//...
Optional<MyClass>.some(myObj)
the accompanying stuff every time... This is where the Swiftenum Optional
Int
You can't pour borscht into the word "plate" can you? You need an object - a plate.
It turns out that there is an Optional type in the brain that combines a word (which is essentially non-material = null) and a real object / type ... With the compiler somewhere + - everything is the same.
(Slightly frivolous explanation, but I think it will lead to the right thoughts)
Unlike SQL, Lisp and other technologies where null/nil has semantic semantics and allows you to perform operations in Java, any attempt to apply any method to null throws an immediate NPE. This means that the programmer FORGOT to initialize the object. This is a gross error and the saddest thing is that it is not checked by the compiler. The use of Optional in streams is necessary to protect the application of map/filter from sudden NPE.
The example that the author gave at the beginning of the topic is simply unsuccessful. It doesn't reveal the benefits of Optional. See the article on Baeldung's website. She is more visual.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question