For instance, the built in map type returns a pair of values, the first is the actual matched value, the 2nd a boolean. If a key is not found the value is set to the type's zero-value, and the boolean as false. So for a map of string->integer, instead of throwing a NoSuchKey exception or something, just returns 0,false. So there's no mandatory ceremony when you don't care.
// don't care
value = map.get(key);
do bleh
// care
if (map.containsKey(key)) {
do blah
} else {
value = map.get(key);
do bleh
}
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.
value = map.get(key);
if (null == value) {
// Handle no value in the map
}
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.
So this guy goes on about how bad unchecked exceptions are, then waxes poetic about Go's, erm, unchecked exceptions.
To add to the weirdness, he seems to think that most people like checked exceptions, when in fact he appears to be very much in the minority.
>>> a = {}
>>> a['foo']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: 'foo'