From: Gavin Sinclair <gsinclair@...>
Date: 2004-11-18T10:41:00+09:00
Subject: Re: assert

On Thursday, November 18, 2004, 11:53:15 AM, Florian wrote:

> Gavin Sinclair wrote:

>>>Problem with using assert() for the method name is that test/unit 
>>>already uses it for stating what a test ought to produce. It seems 
>>>likely that you will have test/unit style assert()s and breakpoint style
>>>assert()s (which I'd like to call assumptions) in the same code base.
>> 
>> And they are completely different things, so should not be toggled
>> from one to the other with a global switch.  A typical test case will
>> have dozens or hundreds of asserts, but only one or two breakpoints.
>> And the breakpoints are very temporary; once you've worked out what's
>> going on, you remove them.
>> 
>> Testing and debugging are very different.

> I agree with you here though I think it can still make sense to toggle
> between different implementations of assume(). For example it might be a
> good idea to log the failed assumption into a warning log file for 
> production applications and so on.

That it can make sense is one thing, but delivering an API that makes
sense is another :)  10 different people would want assume() to do 6
different things in 3 different contexts.  Trying to account for all
that seems futile.

Hopefully people can use the available software to do the things they
want to do (if it's logging in production, breakpoints in testing, or
whatever).  If they can't, they can suggest improvements.

Gavin