# Assert **URL:** \ **Category:** ruby-talk\ **Created:** [17 November 2004 17:16 UTC](https://rubytalk.org/t/assert/14849 "2004-11-17T17:16:07Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Jeff\_Wood2](https://avatars.discourse-cdn.com/v4/letter/j/a8b319/32.png) [@Jeff\_Wood2](https://rubytalk.org/u/Jeff_Wood2)\ **Post date:** [17 November 2004 17:16 UTC](https://rubytalk.org/t/assert/14849/1 "2004-11-17T17:16:07Z")
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... Anyways, I'd be happy with either... # One time call to switch on irb asserts. irb\_assert true . . . assert b == 5 ... or maybe just irb\_assert as the syntax for an assert that causes an IRB session ... assert b == 5 # throws exception irb\_assert b == 5 # starts irb ...just throwing ideas. j. ---
**Author:** ![Florian\_Gross](https://avatars.discourse-cdn.com/v4/letter/f/e9a140/32.png) [@Florian\_Gross](https://rubytalk.org/u/Florian_Gross)\ **Post date:** [17 November 2004 18:33 UTC](https://rubytalk.org/t/assert/14849/2 "2004-11-17T18:33:15Z")
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. ---
**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\ **Post date:** [17 November 2004 22:44 UTC](https://rubytalk.org/t/assert/14849/3 "2004-11-17T22:44:13Z")
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 > **···** > > 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. ---
**Author:** ![Jean-Hugues\_ROBERT](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@Jean-Hugues\_ROBERT](https://rubytalk.org/u/Jean-Hugues_ROBERT)\ **Post date:** [18 November 2004 09:59 UTC](https://rubytalk.org/t/assert/14849/4 "2004-11-18T09:59:22Z")
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 > **···** > > 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. > > ------------------------------------------------------------------------- > Web: [@jhr is virteal, virtually real](http://hdl.handle.net/1030.37/1.1) > Phone: +33 (0) 4 92 27 74 17 ---
**Author:** ![Florian\_Gross](https://avatars.discourse-cdn.com/v4/letter/f/e9a140/32.png) [@Florian\_Gross](https://rubytalk.org/u/Florian_Gross)\ **Post date:** [18 November 2004 00:53 UTC](https://rubytalk.org/t/assert/14849/5 "2004-11-18T00:53:15Z")
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. ---
**Author:** ![Jean-Hugues\_ROBERT](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@Jean-Hugues\_ROBERT](https://rubytalk.org/u/Jean-Hugues_ROBERT)\ **Post date:** [18 November 2004 09:59 UTC](https://rubytalk.org/t/assert/14849/6 "2004-11-18T09:59:31Z")
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 > **···** > > 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 > > ------------------------------------------------------------------------- > Web: [http://hdl.handle.net/1030.37/1.1](http://hdl.handle.net/1030.37/1.1) > Phone: +33 (0) 4 92 27 74 17 ---
**Author:** ![Florian\_Gross](https://avatars.discourse-cdn.com/v4/letter/f/e9a140/32.png) [@Florian\_Gross](https://rubytalk.org/u/Florian_Gross)\ **Post date:** [18 November 2004 15:43 UTC](https://rubytalk.org/t/assert/14849/7 "2004-11-18T15:43:12Z")
Jean-Hugues ROBERT 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. > > 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 This is an interesting idea. I think I will try it out. ---
**Author:** ![Its\_Me](https://avatars.discourse-cdn.com/v4/letter/i/958977/32.png) [@Its\_Me](https://rubytalk.org/u/Its_Me)\ **Post date:** [21 November 2004 04:48 UTC](https://rubytalk.org/t/assert/14849/8 "2004-11-21T04:48:08Z")
> 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 I like this the best of all I've seen so far. ---
**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\ **Post date:** [18 November 2004 01:41 UTC](https://rubytalk.org/t/assert/14849/9 "2004-11-18T01:41:00Z")
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 > **···** > > 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. ---
**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\ **Post date:** [21 November 2004 23:24 UTC](https://rubytalk.org/t/assert/14849/10 "2004-11-21T23:24:11Z")
This is a good idea to an extent. I doubt how much it would be used in practice. To me, the use-cases for production and debugging are so different that the same code can't serve them both. Anyway, this kind of functionality is the responsibility of an Assumptions framework. (To avoid clasing with Test::Unit::Assertions.)   require 'assumptions'   Assumptions.configure do |a|     a.in\_debug { start\_irb }     a.in\_production { throw\_exception }     a.custom { ... }   end   Assumptions.current\_mode = :debug   ...   customers.each do |c|     assume c.full\_name == [c.first\_name, c.last\_name].join(' ')   end What I'm saying is that this functionality can't reasonably be built into a single method ("assert") and distributed. The above code is, to my mind, as simple as possible, but no simpler. Why not create something like this called Assumptions? Then use the top-level "assume" method everywhere. If it's good, I'll include it in dev-utils, because it's obviously a good fit. But I have no interest in creating it myself: it sounds a lot more useful in theory than in practice. Cheers, Gavin > **···** > > On Sunday, November 21, 2004, 3:48:08 PM, itsme213 wrote: > > > > 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 > > > I like this the best of all I've seen so far. ---
**Author:** ![Matt\_Armstrong](https://avatars.discourse-cdn.com/v4/letter/m/41988e/32.png) [@Matt\_Armstrong](https://rubytalk.org/u/Matt_Armstrong)\ **Post date:** [22 November 2004 07:07 UTC](https://rubytalk.org/t/assert/14849/11 "2004-11-22T07:07:44Z")
Gavin Sinclair \ writes: [...] > > > 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 > > > I like this the best of all I've seen so far. > > This is a good idea to an extent. I doubt how much it would be used > in practice. To me, the use-cases for production and debugging are > so different that the same code can't serve them both. [...] >   require 'assumptions' > >   Assumptions.configure do |a| >     a.in\_debug { start\_irb } >     a.in\_production { throw\_exception } >     a.custom { ... } >   end > >   Assumptions.current\_mode = :debug [...] > Why not create something like this called Assumptions? Then use the > top-level "assume" method everywhere. If it's good, I'll include it > in dev-utils, because it's obviously a good fit. But I have no > interest in creating it myself: it sounds a lot more useful in > theory than in practice. I doubt I would ever use this. If I want production code throwing exceptions, I will either explicitly code the call to raise with an appropriate exception class or let the built in class do it (array bounds, etc.). I wouldn't want generic "assertion failed" exceptions being thrown. > **···** > > > On Sunday, November 21, 2004, 3:48:08 PM, itsme213 wrote: > > -- > matt