Hacker News Reader

Comment by pacala | Hacker News Reader

Sure, and you've got to check the boolean if you care. Which is almost the same as the (gasp) Java code:

    // don't care
    value = map.get(key);
    do bleh

    // care
    if (map.containsKey(key)) {
      do blah
    } else {
      value = map.get(key);
      do bleh
    }

To be clear, there are two kinds of errors:

1. The code is screwed up. Java runtime exception, log and hope someone is paying attention to the logs.

2. The world is screwed up. Java checked exception, catch and return a nice message to the user.

View on HN

It appears your code will find the value _twice_. That is less than ideal and not equivalent at all.

If an assumption can be made that you won't put null values into the map then it can be rewritten where it doesn't need to do the check described above:

  value = map.get(key);
  if (null == value) {
    // Handle no value in the map
  }

Any class correctly implementing Map in Java won't throw an exception if there is no value for an input key (http://docs.oracle.com/javase/6/docs/api/java/util/Map.html#...) and some don't allow you to put null values in to begin with (http://docs.oracle.com/javase/6/docs/api/java/util/Hashtable...).

I think one of the points of the OP's article is that in Go you don't have to code like you've done here, where a single return value means one of two things (in your example: value in the map, or special reserved value that indicates the key wasn't found in the map). Go is cleaner, even if it's just a small improvement.

The argument used to be how "Go got exceptions right".

Now, it appears that the argument is about how to save a trivial amount of work for the CPU, when it's unclear whether this is a bottleneck, or whether the JIT can optimize away the two calls, or, in the remaining 1% of the cases, using the null idiom makes this a non-issue.

All at the cost of spending 1 of my 7 brain registers to handle "mandatory ceremony" of adding a _ to every map.get call, regardless of whether I actually know that the given map access should never see an unmapped key, which is the vast majority of cases in my day-to-day coding experience.

At the very best, the argument is about "multiple return values are useful in some cases". But tread carefully, lest every caller has to worry about useless return values.

Reply on news.ycombinator.com