Assert and the optional Message

[Timon Gehr]

On 03/09/2012 08:29 PM, H. S. Teoh wrote:
> On Fri, Mar 09, 2012 at 01:37:38PM -0500, Jonathan M Davis wrote:
>> On Friday, March 09, 2012 09:59:42 H. S. Teoh wrote:
> [...]
>>> This opens up the question of, what's the *recommended* way of
>>> writing unittests that check for these sorts of stuff?
>>>
>>> For example, I believe in being thorough in unit tests, so I like to
>>> use them to verify that the complicated in-contract I just wrote
>>> actually prevents the erroneous calls that I *think* it prevents.
>>> But if catching AssertError's may leave the program in an undefined
>>> state, then that pretty much invalidates any further testing past
>>> that point (the program may appear to work when compiled with
>>> -funittest but actually fail in release mode).
>>
>> If you're testing that contracts throw when they're supposed to,
>> you're going to have to be very careful. Depending on what code is
>> involved, catching the AssertError could have no problems whatsoever.
>> For example
>>
>> assertThrown!AssertError(func(5));
>>
>> void func(int i)
>> in
>> {
>>   assert(i == 2);
>> }
>> body
>> {}
>>
>> wouldn't be a problem at all. There are no destructors, scope
>> statements, or finally blocks involved. But something like
>>
>> assertThrown!AssertError(foo(5));
>>
>> int foo(int i)
>> out(result)
>> {
>>   assert(result = == 2);
>> }
>> body
>> {
>>   Bar bar;
>>
>>   return i;
>> }
>>
>> could have issues if Bar has a constructor than needs to run. You just
>> need to understand that destructors, scope statements, and finally
>> blocks are not guaranteed to be run if an Error is thrown and avoid
>> catching Errors in cases where they'd be skipped (or know enough about
>> the state that the program would be in if they _were_ skipped to know
>> that it's not going to cause problems).
>>
>> Personally, I think that checking contracts is overkill, but you can
>> do it if you're careful.
> [...]
>
> Hmph. Well, then that defeats the purpose of checking contracts, because
> checking contracts is only justifiable if it's complex enough, which
> means that it's liable to involve things like dtors and scope
> statements.  It's silly to want to check a trivial contract like
> assert(x>0);, because if something *that* simple can go wrong, then so
> can the unittest, so you're not proving anything at all.
>
> But this isn't that big a deal. One could argue that if a contract is
> convoluted enough to warrant a unit test, then perhaps most (or all) of
> its complexity should be factored out into a separate, unit tested
> function, which is then just invoked from the contract.
>
> (I find this a bit ironic, since TDPL states that the reason contracts
> allow statements is so that complicated conditions can be tested for,
> rather than being limited to just a single expression, as is the case in
> most other languages that support DbC. Now it seems that simple
> contracts are the way to go.)
>
>
> T
>

Jonathan is just speculating. And I think he is wrong.