8 ms·

I'm kind of surprised there's not a means (to my knowledge, at least) to crash/throw an exception upon sending a message to nil for people who want to better en

I'm kind of surprised there's not a means (to my knowledge, at least) to crash/throw an exception upon sending a message to nil for people who want to better ensure their code doesn't have lurking issues like this. I suppose it'd have to be smart enough to filter out system frameworks to be useful, but I'd imagine that to be do-able.

jdmichal 12y ago
Why not just some old-fashioned input guarding? if (input == nil) haltAndCatchFire(); Or whatever the Objective-C syntax for that is.
- glhaynes 12y ago
  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.)
chc 12y ago
There is a means to do that: http://ddeville.me/2013/06/ruby-like-nil-messaging-in-objective-c/ http://ddeville.me/2013/06/ruby-like-nil-messaging-in-object... I have a feeling it wouldn't work well in practice if you made the handler raise an exception. As the author notes, you're not the only one sending messages, and Cocoa will probably crash your program with a nil message send sooner or later. But you might be able to use it to find out where it's happening, at least.
mikeash 12y ago
There was, in the form of the -fno-nil-receivers compiler flag. It looks like clang doesn't support this flag. I'm guessing nobody used it. You'd have to be really careful when turning it on, since you're effectively using a language that's similar but not quite identical to Objective-C, and which will crash on lots of legal and sensible Objective-C code.

jdmichal 12y ago

Why not just some old-fashioned input guarding? if (input == nil) haltAndCatchFire(); Or whatever the Objective-C syntax for that is.

glhaynes 12y ago
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.)

chc 12y ago

There is a means to do that: http://ddeville.me/2013/06/ruby-like-nil-messaging-in-objective-c/ http://ddeville.me/2013/06/ruby-like-nil-messaging-in-object... I have a feeling it wouldn't work well in practice if you made the handler raise an exception. As the author notes, you're not the only one sending messages, and Cocoa will probably crash your program with a nil message send sooner or later. But you might be able to use it to find out where it's happening, at least.

mikeash 12y ago

There was, in the form of the -fno-nil-receivers compiler flag. It looks like clang doesn't support this flag. I'm guessing nobody used it. You'd have to be really careful when turning it on, since you're effectively using a language that's similar but not quite identical to Objective-C, and which will crash on lots of legal and sensible Objective-C code.