dereferencing null

[Mantis]

06.03.2012 8:04, Chad J пишет:
> On 03/06/2012 12:07 AM, Jonathan M Davis wrote:
>>
>> If you dereference a null pointer, there is a serious bug in your 
>> program.
>> Continuing is unwise. And if it actually goes so far as to be a segfault
>> (since the hardware caught it rather than the program), it is beyond 
>> a doubt
>> unsafe to continue. On rare occasion, it might make sense to try and 
>> recover
>> from dereferencing a null pointer, but it's like catching an 
>> AssertError. It's
>> rarely a good idea. Continuing would mean trying to recover from a 
>> logic error
>> in your program. Your program obviously already assumed that the 
>> variable
>> wasn't null, or it would have checked for null. So from the point of 
>> view of
>> your program's logic, you are by definition in an undefined state, and
>> continuing will have unexpected and potentially deadly behavior.
>>
>> - Jonathan M Davis
>
> This could be said for a lot of things: array-out-of-bounds 
> exceptions, file-not-found exceptions, conversion exception, etc.  If 
> the programmer thought about it, they would have checked the array 
> length, checked for file existence before opening it, been more 
> careful about converting things, etc.
>
It's different: with array-out-of-bounds there's no hardware detection, 
so its either checked in software or unchecked (in best case you'll have 
access violation or segfault, but otherwise going past the bounds of 
array leads to undefined behavior). Both file-not-found and conv 
exceptions often rely on user's input, in which case they do not 
necessarily mean bug in a program.

> To me, the useful difference between fatal and non-fatal things is how 
> well isolated the failure is.  Out of memory errors and writes into 
> unexpected parts of memory are very bad things and can corrupt 
> completely unrelated sections of code.  The other things I've 
> mentioned, null-dereference included, cannot do this.
>
> Null-dereferences and such can be isolated to sections of code.  A 
> section of code might become compromised by the dereference, but the 
> code outside of that section is still fine and can continue working.
>
> Example:
> [...]
> And if riskyShenanigans were to modify global state... well, it's no 
> longer so well isolated anymore.  This is just a disadvantage of 
> global state, and it will be true with many other possible exceptions 
> too.
>
> Long story short: I don't see how an unexpected behavior in one part 
> of a program will necessarily create unexpected behavior in all parts 
> of the program, especially when good encapsulation is practiced.
>
> Thoughts?
>
If riskyShenanigans nullifies reference in a process, then it must check 
it before dereferencing. There's obviously a bug, and if program will 
leave a proper crash log you shouldn't have problems finding and fixing 
this bug. If you don't have access to function's source, then you cannot 
guarantee it's safeness and isolation, so recovering from exception is 
unsafe.