What about instead of having non-nullable types - do what objective-c does and 'drop' calls to null objects. There's been a number of times that instead of my application blowing up from a null exception, whatever feature my user was using just didn't work, but the rest of the application ran fine and they could report the bug to me. It's a much nicer user experience to have the car 'not' blow up if the AC button isn't working.
There are very few problem domains where "do something, even if it's the wrong thing" is better than refusing to run. Perl and PHP have both rightly been criticized for this sort of thinking.
I write automated trading software. If I created a bug, I'd much prefer my program just stop working rather than no-op out a hedging routine or no-op out a regulatory compliance routine. There are also plenty of safety-critical applications where a machine would be perfectly safe if it just stopped working, but would kill someone if it no-opped out a routine. I could see a photo hosting site accidentally giving people without accounts access to everyone's private photos because a filtering routine got no-opped out.
I'll grant you that there are a few small domains where this would be desirable behavior, but I think if it's that much of an advantage, those domains should have domain-specific languages. Skipping method calls on null objects is a terrible feature for a general purpose programming language.
This. One of the most important things I've learned over the years is fail early and verbosely. My code is always littered with pre and post condition checks. As a side effect, we discover 99%+ of bugs before production every time.
I think that in the case of unforeseen error in an application, the program should blow up instead of dropping calls to null objects and continuing on as if nothing has gone wrong.
I would not want to work on code that relies on this type of behavior since it would be so easy to overlook. Every time an object gets deferenced I would have to consider that it might no-op and consider how that might affect the rest of the program's execution.
If you really want to 'drop' calls to null objects, be explicit about it and only make the call inside of a conditional that checks that the object is not null. Your fellow programmers will thank you.
Most of the time it is much better that a program crashes instead of silently operating under incorrect assumptions. This is particularly true if the software is doing something critical. But even if it's a casual game, do you want to risk corrupting your costumers' saves?
