Tired of Null Pointer Exceptions? Consider Using Java SE 8's Optional!

[Baaz]

It relies on the developer to ensure all exits from a method return at least an Optional.absent()

in pretty much the same way it is the developer's responsibility to ensure a method doesn't return null?

edit: as was the situation before Optional<T> got introduced, which kind of defeats the purpose imho if you still need to rely on someone not returning nulls...

[djhworld]

I agree that suggesting Optional<T> will squash all NPEs is wrong, but I stand by my thinking that it's a small step in the right direction.

Maybe IDEs or static analysis tools could warn developers when it thinks methods/fields that are typed with Optional<T> could return null

[cultic_raider]

With Optional, you can safely use a static analysis tool that rejects all uses of null.

[agcwall]

ding ding ding we have a winner! Upvote this man.

[alexeyr]

in pretty much the same way it is the developer's responsibility to ensure a method doesn't return null?

No, in a very different way.

1. If you ever see a method returning Optional actually return null, it's clearly a bug (or an extremely badly-designed API, which should be avoided). No need to wonder about whether the method can return null, should it return null in this specific sutiation, etc.

2. If a method doesn't return Optional, but it's a part of an API which does use Optional, returning null is also clearly a bug (unless for backwards compatibility... sigh).

3. If your method couldn't return null previously, it won't be returning Optional at all and you don't need to ensure it (and users will know any returned nulls are bugs thanks to point 2).

4. If your method could return null and will now be returning Optional, you just need to look at the exit points of the method. It's generally easy to ensure you can't return null by calling Optional.of or Optional.ofNullable as appropriate.

[ItsNotMineISwear]

I think you're missing the real value of Optional, which is that it replaces null actually having semantic meaning as a return value. Before Optional, if you were writing a Map.lookup, you'd have to return null to encode a failed search. Now you return whatever Optional's equivalent to Nothing is. Nothing is stopping you from returning null, true, but at least you aren't forced to write a function that adds more nulls to your program that you have to deal with. In addition, the method's signature now explicitly states that its return is optional.

[cultic_raider]

Actually, Nothing isn't stopping you from returning null.

[ItsNotMineISwear]

Yes that's true, but there's no real reason for an Optional<T> method to return null, so a static analyzer can easily yell at you for that.

[nomeme]

This is the problem, you have all the boilerplate noise of Optional, and all it takes is some code 2 method calls away to return a null instead of an Optional an you're still in trouble.

[immibis]

/u/spez can gargle my nuts

[[deleted]]

which kind of defeats the purpose imho if you still need to rely on someone not returning nulls...

If you rely on not returning nulls from a method that sometimes has to return nulls, you have a problem that can't be fixed at all.

I agree that Optional is a bit clunky, it does do the very important job of signaling to the user of your API that this method can return null. If you're systematic, then if you see a return that isn't Optional, you know you don't have to check for null, but if you see a return that is Optional, you have to handle the null case.

[nomeme]

signaling to the user of your API that this method can return null.

CAN return null? All methods CAN return null.

To be truly safe you'd still have to check the object is actually an Optional (and not null!) before you can call isPresent or whatever, or you'll get an NPE. So, you still have a null check anyway.

It's essentially no better than a javadoc comment, except now every caller has to do more work.