null dereference exception vs. segfault?

[Steven Schveighoffer]

On Mon, 02 Aug 2010 00:59:42 -0400, Ryan W Sims <rwsims at gmail.com> wrote:

> The following code fails with a "Bus error" (OSX speak for "Segfault,"  
> if I understand correctly).
>
> // types.d
> import std.stdio;
>
> class A {
>      int x = 42;
> }
>
> void fail_sometimes(int n) {
>      A a;
>      if (n == 0) {
>          a = new A;  // clearly a contrived example
>      }
>      assert(a.x == 42, "Wrong x value");
> }
>
> void main() {
>      fail_sometimes(1);
> }
>
> It's even worse if I do a 'dmd -run types.d', it just fails without even  
> the minimalistic "Bus error." Is this correct behavior? I searched the  
> archives & looked at the FAQ & found workarounds (registering a signal  
> handler), but not a justification, and the threads were from a couple  
> years ago. Wondering if maybe something has changed and there's a  
> problem with my system?

I'm not familiar with dmd -run, but you should be aware that asserts are  
not compiled into release code.

Try changing the assert to this:

   if(a.x != 42) writeln("Wrong x value");

FWIW, D does not have null pointer exceptions, even in debug mode.  It's  
an oft-debated subject, but Walter hasn't ever budged on it.  His view is  
that you should use a debugger to see where your code is failing.  We have  
pointed out countless times that often it's not possible to have a  
debugger at hand, or even be able to reproduce the issue that caused the  
segfault while in a different environment.  I don't know if we'll ever see  
null pointer exceptions, but I'd love them in debug mode only, or at least  
to see a stack trace when it occurs.  The latter can be done without  
Phobos/dmd help if someone can write such a signal handler function.  I  
don't know enough about stack traces to understand how to do it.

-Steve