From: Jean-Hugues ROBERT <jean_hugues_robert@...>
Date: 2004-11-18T18:59:31+09:00
Subject: Re: assert

At 07:44 18/11/2004 +0900, you wrote:
>On Thursday, November 18, 2004, 5:33:15 AM, Florian wrote:
>
>> Wood, Jeff wrote:
>
>>> It's a semantic thing, but you could also go with an #ensure name
>>> But, I guess I have a question, why not just have a function that
>>> switches asserts to either raise an exception or cause an IRB
>>> session?  that way you could KNOW your code isn't going to break into
>>> IRB in it's production environment, unless you specifically ask it
>>> to...
>
>> 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.
>
>Gavin

I too don't feel like assert() and breakpoint() are interchangeable.
However, I do feel like assert failure leading to the same effect
as breakpoint() is a good thing, when debugging.

Yours,

    JeanHuguesRobert

-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17