Null references (oh no, not again!)

[Denis Koroskin]

On Wed, 04 Mar 2009 13:55:57 +0300, Walter Bright <newshound1 at digitalmars.com> wrote:

> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message  
>> news:gole1d$23v4$1 at digitalmars.com...
>>> Rainer Deyke wrote:
>>>> Writing an assertion for every non-nullable reference argument for  
>>>> every
>>>> function is tedious.
>>> It's also quite unnecessary. The hardware will do it for you, and the  
>>> debugger will tell you where it is.
>>>
>>  Yes...at run-time.
>
> Asserts only fire at run-time, too. This is why I said the asserts are  
> pointless.
>
>> And even then only if you're lucky enough to hit all of the code paths  
>> that lead to a null-reference during testing. It might not cause  
>> data-corruption, but it does cause a crash.
>
> It's not *remotely* as bad as data corruption. Back in the bad old DOS  
> days, a data corruption problem could, and often *did*, completely  
> scramble your hard disk. Having protection against this in hardware was  
> an enormous improvement.
>
> Things were so bad on DOS with this I'd develop code on a different  
> system entirely that had memory protection, then only afterwards port it  
> to DOS as a last step.
>
>
>> A crash might not typically be as bad as data-corruption, but both are  
>> still unnaceptable in professional software. Plus, a crash *can* be  
>> nearly as bad, if not equally bad, as data-corruption when it occurs in  
>> something mission-critical. This is not a problem to be taken lightly.
>
> I've worked with mission-critical software. You absolutely do NOT rely  
> on it never failing. You design it so that when it fails, and it WILL  
> fail, it does not bring down your critical system.
>
> I started my career doing flight critical mechanical designs for Boeing  
> airliners. I had it pounded into me that no matter how perfect you  
> designed the parts, the next step is "assume it fails. Now what?" That  
> is why Boeing airliners have incredible safety records.
>
> Assume the parts break. Assume the hydraulics are connected backwards.  
> Assume all the fluid runs out of the hydraulics. Assume it is struck by  
> lightning. Assume it is encased in ice and frozen solid. Assume the  
> cables break. Assume a stray wrench jams the mechanism. Assume it rusts  
> away. Assume nobody lubricates it for years. Assume it was assembled  
> with a bad batch of bolts. Etc.
>
> If software is in your flight critical systems, the way one proceeds is  
> to *assume skynet takes it over* and will attempt to do everything  
> possible to crash the airplane.

Assume you got a null-derefence under Linux. How are you going to recover from it? You can't catch the NullPointerException, so your program will fail and bring down the whole system *anyway*.