SHORT Re: Suggestion: "fix" assert(obj)

[Ary Manzana]

But... thinking a little more, it may be the programmer's fault, 
actually, to think that someObject is not null. If you call 
assert(someObject.property) then you still get a segfault if someObject 
is null, and here it doesn't seam reasonable for the compiler to check 
if someObject is null.

Ary Manzana escribió:
> The problem in question is that assert(someObject) doesn't check first 
> that someObject is not null, so if it's null, calling it's invariant 
> results in a segmantation fault. In code:
> 
> assert(someObject);
> 
> becomes
> 
> assert(invariantOf(someObject));
> 
> (where invariantOf is a ficticious function that is the invariant of the 
> object)
> 
> You can avoid segmentation fault by making the compiler rewrite
> 
> assert(someObject);
> 
> to
> 
> assert(someObject !is null, "someObject is null");
> assert(invariantOf(someObject));
> 
> Why not do it? In the first case you get a segfault, in the second you 
> get a clear "Assert failed in line ..., someObject is null".
> 
> Jascha Wetzel escribió:
>> Ary Manzana wrote:
>>> You'll waste less time to fix the bug if you know which is the line 
>>> that causes trouble, instead of doing these three steps: compiling 
>>> with symbolic debug info, launching the program again and see where 
>>> it crashes.
>>>
>>> You could even fix the bug by just looking at line 178, without 
>>> debugging.
>>
>> there is no way how access violations can have line numbers without 
>> adding debug symbols (read: line numbers) to the executable.
>> imho, using -g should be default during development and testing.