What is the real benefit of returning Optional<Map<String, String>> rather than just an empty Map<String, String> [duplicate]

Question

If my code returns Map<String, String> for sure, but could be empty. Is there a benefit of converting it to return Optional<Map<String, String>>. Would it add any benefit to empty but not null instances?

Answer 1

Like so many subjects in computer programming, It Depends (tm).

The way I use optional is as an alternative to null (in a nutshell). One of its advantages is that it forces the caller to consider that there may not be a returned value, and that this is a valid condition... Consider the quotes from the answers linked above:

absence of a value is a more precise formulation than null

and

Any reader of your code or consumer of your API will be beaten over the head with the fact that there might be nothing there and that a check is necessary before accessing the value.

So when I see the return type signature Optional<Map<String, String>>, I think of it as a return type from a function where an empty Map might be a valid return value, but so is an entire lack of a Map.

Examples of this include getCachedFavoriteColors, findInvalidValuePairs, etc. In the former case, there might not be any any users, which would return an empty Map -- but there might not be a cache value, which would return an invalid Optional. In the second case, there might not be any invalid value pairs, which would again return an empty Map, but there also might not be an Invalidator. You get the idea.

Note that in some of the cases above you might want to throw an exception instead of return an invalid Optional. That's your decision as an API designer.