assert(condition[, message]) patch

[Sean Kelly]

Derek Parnell wrote:
> On Thu, 01 Jun 2006 04:38:50 +1000, Sean Kelly <sean at f4.ca> wrote:
> 
>> Walter Bright wrote:
>>> 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?
>>
>> Some applications ship with asserts left on, and the more information 
>> the user has about why the application just halted the better.  As 
>> others have noted, an optional message also allows state information 
>> to be conveyed, which can be useful in the absence of a core dump.
> 
> And this is a deployment/development strategy that is flawed. It would 
> be better to ship a product without asserts turned on, but if you have 
> to show internal issues to a customer then don't use asserts - use 
> exceptions or similar to do this at run time. Just use asserts for 
> quality assurance prior to shipping.

There's a popular argument connected to contract programming which says 
that it makes no sense to test with contracts enabled and disable them 
in the release code.  I'd prefer not to take sides here, but I do think 
that in instances where the application should halt because a condition 
has not been met, an assert should be used.  If the programmer would 
prefer that the user not see file and line information, he can easily 
catch the error in main, report it however he wants to, and then return.

That said, my real goal here is merely to make assert a bit more 
flexible so users aren't inclined to roll their own error handling 
routines simply because they want to provide context information.  The 
above example just happened to be the first I though of.


Sean