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