Interesting.  Could you expand on "recommends quite sanely that you
should only spin a class if and only if you have an invariant to
protect"? it feels right but I am not sure I get it completely.

Another thing.. one big problems that I have with assertions is
duplication.  Do you assert any method? do you assert on class public
methods? It's very to sprinkle the same assertions all over the place.

On 3/6/06, John Carter <john.carter / tait.co.nz> wrote:
> Unit Tests and DbC assertions are complementary, not exclusive. I always
> do both.
>
> I tend to put the "post condition" assertions in the Unit Tests and
> invariant and pre-condition assertions in the code.
>
> Why?
>
> 1) The pre-condition assertions are "tests of the tests". Test's are code
>     too, therefore have bugs.
>
> 2) Post-conditions are effectively the asserts found in the unit test. ie.
>     If you have strong test coverage, don't bother with post-condition
>     asserts, refactor them into the unit test code.
>
> 2) Client code using my code has bugs and the precondition asserts catch a
>     lot of them very rapidly and at the right point. A the client code Unit
>     test  postcondition assert says the client (or maybe the lower layer)
>     code did vaguely the wrong thing  somewhere someplace sometime. A
>     Precondition assert says the client code violated a pre-condition
>     RIGHT HERE.
>
> 3) Invariant code are Object Sanity Checks. Stroustrup (author of C++)
>    recommends quite sanely that you should only spin a class if and only if
>    you have an invariant to protect. Invariant checking method is a handy
>    way of checking at run time that your class is doing what it was
>    designed to do.
>
> 4) I always throw vanilla Exceptions on assertion failure. It meshes
> nicely with the stacktrace mechanism of Ruby, but so far I can't think of
> any good reason to create a new exception class for them.
>
>
>
> On Mon, 6 Mar 2006, chiaro scuro wrote:
>
> > I would get my assertions to raise exceptions too.  They are just a
> > specific kind of exception, related to the domain of inputs and
> > outputs, different from exceptions generated from something that goes
> > wrong in the middle.
> >
> > What do other people think about the relationship between assertions
> > and exceptions?
> >
> > On 3/6/06, Pat Maddox <pergesu / gmail.com> wrote:
> >>> tests alone however are never exhaustive and cannot prove correctness.
> >>> assertions can catch some types of 'wrongness'.
> >>
> >> Isn't that what exceptions are for?
> >>
> >> def foo(a)
> >>   raise 'Argument can not be negative' if a < 0
> >>
> >>   b = something_that_should_always_be_positive
> >>
> >>   raise 'Something strange happened and b was negative' if b < 0
> >>   b
> >> end
> >
> > --
> > -- Chiaroscuro --
> > Liquid Development: http://feeds.feedburner.com/LiquidDevelopment
> >
>
>
>
> John Carter                             Phone : (64)(3) 358 6639
> Tait Electronics                        Fax   : (64)(3) 359 4632
> PO Box 1645 Christchurch                Email : john.carter / tait.co.nz
> New Zealand
>
> Carter's Clarification of Murphy's Law.
>
> "Things only ever go right so that they may go more spectacularly wrong later."
>
> From this principle, all of life and physics may be deduced.
>
>


--
-- Chiaroscuro --
Liquid Development: http://feeds.feedburner.com/LiquidDevelopment