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

At 03:33 18/11/2004 +0900, you 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.

I suppose that assert() can still be used. The new
version would I have to figure out that it runs in
the context of test/unit. In that context its behavior
would be compatible with test/unit.

The other contexts that assert() should support are:
  - production => throw an exception
  - debugging  => start an irb session
  - custom     => invoke some user provided assert failure handler

My 2 Euro cents,

Yours,

    JeanHuguesRobert

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