5

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?

ssgao
  • 5,151
  • 6
  • 36
  • 52
  • 3
    I recently had a discussion about this with a coworker. It comes down to a matter of opinion, I think, depending on how strongly you believe in Java's `Optional` as a monad. Pragmatically, I prefer the empty map. – Matt Ball Apr 18 '15 at 01:31
  • 1
    Huh, I'd be hard-pressed to see the value of an `Optional>`, personally. But maybe I could be convinced. – yshavit Apr 18 '15 at 02:02
  • 4
    According to Brian Goetz you shouldn't use it with Collections (and Maps as well). See: http://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555 – Nir Alfasi Apr 18 '15 at 03:04

1 Answers1

9

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.

Community
  • 1
  • 1
George Hilliard
  • 15,402
  • 9
  • 58
  • 96
  • 1
    But a Map can be empty -- any user of a Map should know that, so it's equally-head-beaten. I don't see the additional value. In fact, you've created yet _another_ "this is empty"-type state. Now your reference can be `absent()`, of an empty map, or of a non-empty map. That suggests some difference between the first two states, and it's probably not too obvious what that difference is (even in context of the API). – yshavit Apr 18 '15 at 02:06
  • 7
    But (and of course this idea needs to be judiciously applied to the API design): *absence of elements in a Map* is distinct from *absence of the Map*. It is the latter that Optional allows you to express in a concise manner. – George Hilliard Apr 18 '15 at 02:07
  • 2
    It's hard to remember to check for both null and empty maps, oftentimes people will forget and eventually runtime errors are thrown. With an Optional, you can condense the checks for null and empty but initialized structures into one single check. That's what I use them for, and it definitely makes error checking a lot easier. – egracer Apr 18 '15 at 02:48
  • How do you check for empty in Optional? other than `optional.filter(x->!x.isEmpty())`. Seems more verbose. – ssgao Apr 18 '15 at 03:49
  • @thirtythreeforty Of course they're distinct. But can you think of an example in an API where an absent map is _usefully_ different than an empty one? And sure, absence of proof isn't proof of absence... But given that it increases the complexity of your API, I think the onus is on the pro-Optional camp to show a specific case where the distinction is useful. That's what I meant by "I don't see the additional value." – yshavit Apr 18 '15 at 15:47
  • 2
    @yshavit: it doesn’t matter whether you find useful examples. The point is that saying “it’s useful if, and only if, there’s a distinction between absence of elements and absence of the map” is already enough to aid your API design. If you never encounter such a scenario, well then there’s no use for `Optional` in your scenarios. – Holger Apr 20 '15 at 09:18