Suggestion: "fix" assert(obj)

[Frits van Bommel]

Stewart Gordon wrote:
> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
> news:f4s0i8$1vk8$1 at digitalmars.com...
>> Kristian Kilpi wrote:
>>> The problem is that
>>>
>>>   assert(obj);
>>>
>>> does not first check if 'obj' is null.
>>
>> Yes it does, it's just that the hardware does the check, and gives you 
>> a seg fault exception if it is null.
> 
> There are two problems with this.
> 
> Firstly, this'll only work if the class actually has an invariant, and 
> this invariant actually accesses object members (as opposed to merely 
> checking static stuff).

Not true. The mere act of looking up if an objects class has an 
invariant requires access to the .classinfo, causing a segfault. (I 
posted the code earlier in this thread)

> Secondly, given a segfault or AV, how's one supposed to pinpoint the 
> cause? An assert error, OTOH, has a filename and line number attached.  
> It's the same with the more general request of null reference checking - 
> people want an error class that unambiguously indicates dereferencing a 
> null pointer and which gives an immediate clue of where the problem is.

According to Walter: compile with debug info and run in a debugger. 
However, I dislike this option.

The first reason I have for disliking this is that this requires the 
person seeing the error to have a debug build and run it in a debugger 
(requiring a debugger be installed). I can see this being troublesome in 
situations where the person experiencing the error isn't the developer 
(or even a tester). I'd say segfaults in deployed applications would be 
the worst kind, yet those are least likely to be run as a debug build in 
a debugger...

Secondly, what about applications where the segfault doesn't occur 
deterministically? (e.g. a multithreaded application)
Or if the exact situation is just hard to repeat? (e.g. interaction with 
other systems like databases whose state changes between runs[1])

I'd very much prefer it if the first time something like this went wrong 
the application would display as much information as possible without 
requiring debug info + debugger and without requiring the fault be 
duplicated in a new run of the application.


[1]: And might be hard to roll back to the exact state that caused the 
error, for instance because they have multiple clients (that must 
perhaps continue to run during fault isolation?) and/or are 
multithreaded themselves.