Le 2010-07-17 à 1:08, Walter Bright a écrit :
> Yes, for that sequence, the rest are irrelevant. But what I don't
> understand is why is it so bad that they also generate messages, which
> you just ignore looking over the log file?
I don't know about you, but in my regular code I often write my assertions like
this:
int* ptr = getPointer();
assert(ptr !is null);
doSomething(ptr);
The assertion detects that something is wrong and prevents the code from doing
dangerous things when the state is already incoherent. In fact, there isn't
much other use to an assert in regular code than to detect invalid states and
abort.
But then you make it do something different in a unittest:
unittest {
int* ptr = getPointer();
assert(ptr !is null);
doSomething(ptr);
}
Here, moving forward passed the assert creates a seg fault and thus the
following unit tests won't be run. The results could be more or less severe
depending on the exact nature of what the assert guards against. Now you've
already suggested this solution:
unittest {
int* ptr = getPointer();
if (ptr !is null)
doSomething(ptr);
else
assert(0);
}
... which works (both in asserts an in regular code). But this means that
inside unit tests you have to use a different (and more verbose) solution to
guard against invalid state than in your regular code. It's true that you can
train someone to do something in some situation and something else in another,
but it obviously is more complicated and error prone than if you always do the
same thing to get the same result.
Another thing. You might argue that most of the time it poses no problem to
continue after an assert in a unit test; and I'll agree with you. However, it's
not always the case, and it's easy to do a mistake for the dangerous cases
because people are trained to use assert in regular code as a protection. Now,
if you had the reverse -- throwing by default -- you will be overprotective in
many cases (those that won't crash when not throwing), but it could be made
easy to opt-in for the non-throwing behaviour whenever its useful.
--
Michel Fortin
[email protected]
http://michelf.com/
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
