On Monday, 5 March 2012 at 02:32:12 UTC, Chad J wrote:
I hate hate HATE vague error messages that don't help me.
In a lot of cases, getting more info is very, very easy: $ dmd -g -debug test9 $ ./test9 Segmentation fault $ gdb ./test9 GNU gdb (GDB) 7.1 [...] (gdb) r Starting program: /home/me/test9 [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x08067a57 in _Dmain () at test9.d:12 12 bar.foo = 5; (gdb) where #0 0x08067a57 in _Dmain () at test9.d:12 #1 0x0806eaf8 in _D2rt6dmain24mainUiPPaZi7runMainMFZv () #2 0x0806e605 in _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv () #3 0x0806eb3f in _D2rt6dmain24mainUiPPaZi6runAllMFZv () #4 0x0806e605 in _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv () #5 0x0806e5b4 in main () (gdb) print bar $1 = (struct test9.Bar *) 0x0 My gdb is out of the box unmodified; you don't need anything special to get basic info like this. There's two cases where null annoys me though: 1) if it is stored somewhere where it isn't supposed to be. Then, the location of the dereference doesn't help - the question is how it got there in the first place. 2) Segfaults in the middle of a web app, where running it under the same conditions again in the debugger is a massive pain in the butt. I've trained myself to use assert (or functions with assert in out contracts/invariants) a lot to counter these.