[phobos] Silent failure of std.container unittests

[Michel Fortin]

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
michel.fortin at michelf.com
http://michelf.com/