> In a lot (most?) cases where there's a possibility that dict could be nil, the thing you want is for nothing to happen. And therein lies the root error which

> In a lot (most?) cases where there's a possibility that dict could be nil, the thing you want is for nothing to happen. And therein lies the root error which makes this entire blog post misguided. Trivial (hopefully) question: Would you rather fix 1 bug that takes 10 minutes to find, or 10 bugs that take 20 seconds each? Given that 'my code silently just... does.... nothing? That's odd' is tens to perhaps even a hundred times harder to find than 'you assumed this could not be null, right on this very line right here, here is the full stack trace how we got there - it IS null' - NPE is superior to this silent treatment. That's not to say runtime-only null checking (e.g. java without nullity annotations for example) is the only right answer. Far from it. But it's superior to leaving a trail of ticking time bombs like this. In effect, you make a difference choice about the semantic meaning of it. In Objective C, `nil` means: "A sentinel object that is real, has semantic meaning, and that meaning is that it returns nil for all things". Woe is you if you treat it as "An object that indicates the value is unknown or does not apply (no interaction with it was ever expected)". In java, `null` means: "A sentinel value that indicates the value is unknown/unset or does not apply - hence any attempt to interact with it will throw an error". Woe is you if you treat it as a sentinel. But less woeful - you simply get an exception pointing at the line where you made the brainfart. Unfortunately lots of program language ecosystems aren't quite as clear about what nil/null is supposed to actually mean (e.g. java where it's often used as sentinel, and then leads to code littered with `if (x == null || x.isEmpty())` style lines, a clear sign someone is not sticking to a meaning of `null` that works well with that particular language.