Hi Robert,

Thanks for your reply!

> Speaking from memory, I often use BOTH assert and exception. Sometimes
> something looks like a program error which should never happen so I use an
> assert. But should this occur during release mode, it should throw an
> exception.

In this case, the code looks like:

// trap usage of invalid uninitialized boolean

void load(bool & t){

load_binary(& t, sizeof(t));

int i = t;

BOOST_ASSERT(0 == i || 1 == i);

(void)i; // warning suppression for release builds.

}

(see: serialization/archive/basic_binary_iprimitive.hpp)

so if I strip out asserts, nothing happens, and the process just blunders on without reporting any problems. As far as I can see, this assert is not checking for a program error - it's looking to catch an invalid value in the input stream.

I'd also argue that adding a 'throw' after the 'assert' is not the right approach to take. For instance, I may want to test that my code will correctly reject invalid inputs. If the assert is present in debug but not release modes, the behavior will be different in the two cases. And if the assert is in code not my own, I have no reason to expect such a change. IMO asserts should be reserved for situations which can occur only in cases of programmer error, and should in theory not be triggerable by any external input.

So as I see it, this assert should simply be replaced by a throw. Do you agree?

-Gabe