assert(condition[, message]) patch

Oskar Linde oskar.lindeREM at OVEgmail.com
Thu Jun 1 10:04:48 PDT 2006


pragma wrote:
> In a more serious, and on-topic note, I too believe that assert() could stand
> some expansion to allow for more succinct error reporting.  It all comes down to
> the matter of reporting "how and why" something breaks rather than just "where".
> 
> As a preface, I for one do not use an IDE when developing my software.  D seems
> to do pretty well for me without it, although I'm still longing for
> out-of-the-box stack tracing.
> 
> Anyway, so I run some code that trips on an assert, and it coughs up
> "foobar.d(42)" as where I need to look.  The assert has done its job, as I go to
> line #42 and go hunting for the reason behind why it tripped up.  As I'm
> basically flying blind (no watch window and no stack trace), my next step is
> almost always: add a writefln() before the assert to get some more information
> as to how this happened.  Meshing those two steps seems like an obvious choice
> to me.

What I do is redefine the implementation of assert to do:

  *(cast(int *)0) = 0;

That way, I get a segmentation fault and a core dump that the debugger 
(gdb) is able to use to present me with a back trace and (all) local 
variables available for inspection. This is immensely more useful than 
letting assert throw an exception, which means losing all state and 
stack trace information.

/Oskar



More information about the Digitalmars-d mailing list