#optional or not

1 messages · Page 1 of 1 (latest)

topaz osprey
#

so Optional was created to use as a return type. how do you decide whether or not to use Optional for a return type vs returning null? i know some code bases that use optional for all methods that can return null. some other code bases have a mix

real dewBOT
#

<@&987246399047479336> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
So Optional was created to use as a return type. how do you decide whether or not to use Optional for a return type vs returning null? i know some code bases that use optional for all methods that can return null. some other code bases have a mix

When deciding whether to use Optional as a return type vs returning null, it's generally recommended to use Optional when the method may or may not have a value to return, and returning null could lead to potential NullPointerExceptions in the code. By using Optional, you make it explicit that the method may return a value or may not.

However, using Optional for all methods that can potentially return null may lead to unnecessary complexity in the code. It's important to consider factors such as readability, performance, and overall design of the code base when deciding whether to use Optional or simply return null.

Useful links:

- AI generated response
fading echo
#

I heavily tend towards using Optional. null is implicit and it's not always clear if a null check is required without docs. Optional explicitly shares that the absence of a value is possible in the type system and the consumer will consider how to handle it

You also get some fancy helper methods to default/map/unwrap, where of course, null doesn't have any

velvet rain
#

null works well for simple data access, e.g., getting something from a map with map.get(name), where it's implicitly obvious to the developer that sometimes they won't get a result and the value will be null.

Optional makes it more clear to the developer that "this method might not return a value and that's normal, so you need to handle that case explicitly", essentially forcing the developer to consider the case where they don't get a result. So this is very good for methods where it might not be obvious that there might not be a result, e.g., getCurrentUser(). A developer might assume that this always returns a user, so making this return Optional<User> makes it a lot more clear and also forces them to handle the case where a user isn't present.

So as with most questions in programming the answer is "it depends" 🙂

magic tangle
#

I think on your public api boundary, use Optional. What you do in private methods is your business like in the map.get example above. I try not to use null unless it would be a big hassle for some reason.

topaz osprey
#

one reason i've heard for optionals is if you're going to be chaining methods from Optional it might be worth returning optional. when i first started using optional all i did was check isPresent and then called get(). i use ifPresent a bit more now & some other methods when they apply

magic tangle
#

I never use ifPresent isPresent/get

radiant bobcat
#

Optional#map is great

thorny trail
#

however, personally, id often stick to null for methods that are used within the class itself. i.e. when the user/caller of the method is very close to the method itself

#

for example for private helper methods

#

then its generally reasonable to assume that they wont be forgetting to check the return value for presence

#

(but ideally u then also have a proper @Nullable, @NotNull setup)

#

for any method where the user is further away, u generally should be sticking to Optional

silent vale
#

Optional, always

#

(well, for return types at least)

#

When you first start using it, it seems like a drag

#

Once your entire application starts being based on it, it's just flatMap all the way down

#

Which is also why you need a good value class generator. Lombok isn't great. I prefer immutables, they do the "proper" way of returning optionals and still having fields be underlying types

radiant bobcat
#

optional’s going to get a lot better performance wise in the future

#

since it checks all the boxes for being a value class

silent vale
#

oh yeah

radiant bobcat
#

(there’s an optimisation issue Minecraft where thousands of Optionals get stored)

silent vale
#

lol, well you shouldn't store them obviously

radiant bobcat
silent vale
#

ah yeah, but they shouldn't be parameters

#

Should just not call the method in the first place

#

But yeah, shit like this can happen

thorny trail
#

these situations happen when people start misusing/abusing stuff

#

if u use optional as advertised its all gucci

silent vale
#

My most hated code statement: java if (parameter == null) { return null; }

thorny trail
# 
if (foo != null && foo.bar() != null && foo.bar().baz() != null) {
  Baz baz = foo.bar().baz();
  ...
}
#

T_T

silent vale
#

oh yeah, and those are method calls so you should have local vars for all of those 😐

thorny trail
#

yeah 😄

radiant bobcat
#

foo?.bar()?.baz()

#

apparently not what the Java devs want

thorny trail
#

they do

#

u need to follow JEPs

radiant bobcat
#

is it part of valhalla

thorny trail
#

there are various talks about first class null-api

#

also mentioned in most of the conferences

#

here for example

#

but theres more

#

its all coming. just takes a bit

radiant bobcat
thorny trail
#

but theres more
its all coming. just takes a bit

#

step by step