I'm intentionally making it null to see how the new backtraces work.

I know it's because I'm trying to call a method on "null", but If I'm working on a huge code base, how do I debug this kind of issues if I don't have stack trace with line and error number of the error?

I'd like to get at least the stack trace and the error number with the line of the source code that caused the problem, like in golang:

  $ cat main.go
  package main
  
  type Greetings struct {
  }
  
  func (g Greetings) hello() {

  }

  func main() {
	g := &Greetings{} // heap instance
	g = nil           // intentionally shooting myself in the foot like I did in D
	g.hello()
  }
  $ go run main.go
  panic: runtime error: invalid memory address or nil pointer dereference
  [signal 0xb code=0x1 addr=0x0 pc=0x2025]

  goroutine 1 [running]:
  main.main()
	/Users/ride/Documents/main.go:13 +0x15

  goroutine 2 [runnable]:
  runtime.forcegchelper()
	/opt/boxen/homebrew/Cellar/go/1.4.2/libexec/src/runtime/proc.go:90
  runtime.goexit()
	/opt/boxen/homebrew/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 +0x1
  exit status 2

null deference in D doesn't throw exceptions by default on Unix so you won't see the backtrace there.

If you are working in a big codebase and have this come up, you can enable core dumps and run it in a debugger to get far more information than just a line number (and line numbers are there too at least if compiled in debug mode).

does this mean there is not a way to get stack trace on OSX?

I have not tried it myself but there seem to be ways to get a stack trace on Linux.

http://vibed.org/docs#handling-segmentation-faults

I don't know about an automatic one, but running the debugger would still work there too. Or at least it should.

Try valgrind