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