#optional

27 messages · Page 1 of 1 (latest)

lost parcel
#

optional has been out of a while now, i personally dont see optional used a much as null in the codebases i work with. is there a good rule of thumb for when to use optional as a return type over null?

jade lanternBOT
#

<@&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
Optional has been out of a while now, i personally dont see optional used a much as null in the codebases i work with. is there a good rule of thumb for when to use optional as a return type over null?

Using Optional as a return type in Java is primarily about making your API's intention clearer and avoiding explicit null checks. A good rule of thumb:

  • Use Optional as a return type when a method might not return a value, and you want to explicitly signal that absence without risk of NullPointerException.
  • Prefer Optional to avoid returning null, which can be ambiguous and error-prone.
  • Avoid using Optional for fields or parameters, as it’s not designed for that and can add unnecessary overhead.

In contrast, null is still common and sometimes more straightforward, especially in legacy code or performance-critical hotspots. However, Optional encourages better handling of absent values by forcing the caller to consider the empty case.

In summary: Use Optional for return types when you want expressive, null-safe APIs that prevent mistakes. Use null when Optional would complicate code or add overhead without meaningful benefit.

Useful links:

- AI generated response using gpt-4.1-mini model
hollow dawn
#

Optional is normally used as a way to replace null, as you can check Optional.isPresent or Optional.isEmpty or Optional.ifPresent, and you can return an empty optional rather than a null.

Optional was the so called answer to throwing nulls around and getting NPE, iirc been using them for far too long personally

ornate harbor
#

Eh optional in java is so-so

#

java devs got bullied hard by rust devs for not having enough monads so they folded and added optional

#

fact of the matter null or an exception gets the job done in most cases

lost parcel
#

i find optional a bit annoying sometimes so i stick with null, but sometimes i feel like using it

#

im not really consistent about it

median lark
light mason
#

the real way to handle null is to not have null,
structure your code in a way that handle all states, even failing states

#

like, if a method return a list of results, if there is no results, you just return an empty list

terse scroll
#

ideally u should use it always whenever a method has a return type that can sometimes not be present

#

exceptions maybe for private helper methods and special cases like collections

#

but ur default should always be to return optional instead in such a case

terse scroll
#

to force the caller of a method to not forget about the edge case handling

#

as with null, or also other sentinel values (-1 for find() for example) u have the problem that u could use the value without noticing and drag it through ur codebase

#

i.e. not-fail-fast

#

creating situations that are impossible to debug bc when it finally crashes the crash location could be many many methods and lines of code away from the origin of the issue

#

with Optional that cant happen anymore bc as caller you are forced to go through the handling of the edge case in order to get hands on the contained value

#

i.e. u must unwrap in order to use it

#

and bc its just about fail-fast its also totally okay to drop it in private methods and similar

#

bc as the author of a class ur likely to remember that this helper returns nullable/a sentinel value and deal with it properly

#

since the call-sites are so close to the method

#

but as "external user" (not private method) u will forget about it