assert(condition[, message]) patch

Unknown W. Brackets unknown at simplemachines.org
Wed May 31 21:38:04 PDT 2006


Walter,

My most common use for having this is simple.

Consider an open source software.  Various versions of the same software 
are in use, each with different patches applied.

Let's say this happened to dmd, or gdc.  Let's say a compiler error 
occurred... this:

expression.c(379)

Because a patch has been applied to expression.c - a rather long one 
adding support for "x ?: y" or something else like that (maybe a bad 
example) the error actually shows:

expression.c(518)

The user, who has this patch, does not really know much about 
programming, and reports it to the original software developer. 
Eventually, after initial confusion, it becomes clear that patches are 
involved, and these are listed.  Eventually, the bug can be tracked down.

With a compiler, this is really not a common thing.  But with many other 
softwares, this is VERY common.  I have had a huge amount of experience 
with exactly this problem, although not in D.

It was not fun, and caused finding bugs, searching for solutions to 
common problems, and everything much much more difficult and time consuming.

Error messages in this software were eventually revamped to be logged 
with more extensive information.  It became rapidly easier to debug the 
software, and make it robust and bug free.  Searching for errors was no 
longer done by line number, resulting in a much higher rate of return - 
which meant our support team was much less bogged down by those requests.

I realize it doesn't benefit DMD much, but having some way to give more 
information than a line number (which, to some projects, is about as 
useful as dumping the value of a pointer at runtime) is extremely useful 
for many sorts of open source softwares.

It's also useless when you have people using/testing nightlies or 
frequent beta releases, a practice that generally helps to improve 
overall release quality.  You can't even tag the assert with a release 
tag or revision.  Even if not for the patches...

As it is, I guess the solution is simple.  Don't use assert, it's almost 
useless for any robust application development.  Roll your own instead, 
e.g. using if as Brad suggested.

-[Unknown]


> braddr at puremagic.com wrote:
>> I have been toying with D to bring myself up to speed and I found 
>> myself writing
>> a lot of unit tests, always a good thing.  In those unit tests I found 
>> myself
>> writing a lot of blocks like:
>>
>> if (cond)
>> {
>> writefln("some debugging output to make my life easier");
>> assert(false);
>> }
>>
>> I know many don't like unit tests to have output, but I do.
> 
> Why not:
> 
>     assert(!cond); // some debugging output to make my life easier
> 
> ? You'll need to go look at the source anyway when the assert trips, so 
> what advantage is there to print the comment?



More information about the Digitalmars-d mailing list