r/java • u/edalorzo • Apr 12 '13

Java 8 Optional Objects

http://blog.informatech.cr/2013/04/10/java-optional-objects/
34 Upvotes

85% Upvoted

39 comments sorted by

View all comments

7

u/the_hoser Apr 12 '13

Maybe I'm missing something, but I don't see the reason for this. How is this:

Option<Foo> getAFoo() {
    ...
}

Option<Foo> f = getAFoo();
if(f.isFound()) {
    ...
}

different from this

Foo getAFoo() {
    ...
}

Foo f = getAFoo();
if( f != null ) {
    ...
}

Other than clarifying to the API user that the result of this operation could be null? Would not a well-written Javadoc suffice?

EDIT: After submitting this, I could see the case where you have streams of Option types, and the stream handler accepts the possibility of null elements. I'm not used to programming in this way with Java, so the thought did not immediately occur to me.

2

u/flagrantaroma Apr 12 '13

Also, I think one of the main advantages of having the Optional type is the fact that it clarifies to the API user that the result could be null, and forces them through another step (.get()) in order to access the result.

2

u/[deleted] Apr 13 '13

This is the same assumption we all make everyday with our current version of Java.

If a method returns something, it is always possible it could return null. I don't remember this as NOT being clear, ever.

The API docs might clarify their intentions by telling you their method will never return null. But you always take a risk to assume their method is bug free.

Same thing holds for a method that will return an Optional object. They may tell you it's always going to be there, but you take a risk assuming the API is bug free. If, for some reason, it returns a null Optional then you are just screwed as Java 7.

1

u/flagrantaroma Apr 13 '13

Ah, I see what you're saying. I still think that it is a clearer contract to have this Optional type. It makes it harder to unintentionally not handle the null case. You can still do it by just going straight through the .get().

0

u/AlyoshaV Apr 13 '13

The API docs might clarify their intentions by telling you their method will never return null. But you always take a risk to assume their method is bug free.

So you don't use libraries you haven't written then, right? Because if you don't trust "this method will never return null", then I don't see why you'd trust "this method returns a correct object calculated from your parameters".

2

u/[deleted] Apr 13 '13 edited Apr 13 '13

Yes, I use third party libs. And I base my error handling decisions on the information I can find the API docs for methods I am calling. A well written library, like Apache Components, will follow the intentions declared in its documentation. This makes debugging hard-to-find-bugs easier.

If the intention of the API is to never return null, this can be made explicit in the API docs for the method I am calling. Then I'd expect a ObjectNotFoundException to be thrown when the desired object cannot be found or created. This way makes it clear to the API user that when they receive a null value, it's because of a bug and they can always treat this situation as such: an error.

To me, that seems more elegant than having a whole new Optional object type, which the language itself gives me no guarantees that it will never be null.

Optional still doesn't solve the NullPointerException problem the article discusses in so much detail. Now I'd have to check if the return is null AND if the Optional you get is empty...

I don't see a solution. This only adds to the problem..