3 ms·

To make a scheme like that work, you'd essentially need to check before every single method invocation in your entire program because the issue — such as it is

To make a scheme like that work, you'd essentially need to check before every single method invocation in your entire program because the issue — such as it is — is with method invocations being made against nil references, not with nil parameters being passed in as arguments to method calls. I was imagining something more like a modified version of the runtime's objc_msgSend() C function (which Obj-C method invocations get compiled into) that guarded against that, but you do make me realize that such checks could conceivably be automatically tacked on at build time. Anyway, I'm not entirely sure how useful such a thing would be, but I am curious how often my code (unintentionally) makes calls against nil and I've just never noticed because it doesn't cause harm.

jdmichal 12y ago
Ah, I see. I think that at some point you have to trust something. The only true way is to never trust any of your inputs. This is, after all, what the JVM does in order to throw out kindly NullPointerExceptions on null dereferences. But realistically that is extremely consuming and has little payoff in most cases. I typically do not trust arguments, but do trust the results of functions to be what the documentation says it will be. Static analysis could potentially go a long way here to expose values that could be potentially "infected" with nil. (And, for all I know, the JVM JIT could do exactly this to skip checks on provably non-null values.)