[boost] Re: Re: Proposal: Design by Contract / Pre&Postconditionslibrary

From: Yariv Tal (yariv_tal2003_at_[hidden])
Date: 2005-04-25 02:45:12

Hi Brian,

"Brian Braatz" <brianb_at_[hidden]> wrote in message
news:7770D1D3403FEB4F9C05C20A923136CC94891C_at_PIONEER.corp.rmtg.com...
> General 2 cents:
>
> About a year ago I built a library for internal use along the lines
> being discussed in this thread.
>
> (for the curious what I did was hook logging and tracing to the
> Precondition and postcondition)
>
> After I got it all done, I said to myself, OK I am now going to USE this
> code and abide by it's rules.
>
> I found that very difficult to do, because of my OWN difficulties in
> doing that I have shelved this library for our internal usage. (i.e from
> a practical nature it would be hard to get people (myself included) to
> continue to use it)
I think you are right, from one point of view.
The original DbC idea is to sit down and write the pre/post conditions
before
actually programming any line of code.
This is hard and most people don't want to do it, me included (no matter
how effective it is).

BUT, I _have_ been using the library as a post-design tool.

>
> I ask the people thinking about this lib, to sit down and try to write
> 10 or so functions and get a sense for if you would actually USE it.

I found it useful in three major case groups:

1) The code I wrote had to follow a lot of consistency rules that were
not immidiately clear from the requirements or external documentation.
I could document these as comments, but writing them as pre & post
conditions is less ambigous, sometimes more clear, and I get the
added bonus of runtime testing that the rules hold.
Even better - I sometimes found out that the rules didn't hold not
because of a bug in the code but simply because I was wrong
writing them down. So, I got the added benifit of ensuring that
the documentation (=the consistency rules) actually matches what
goes on in the code.

2) All of those times I would normally use an assert.
I use the pre/post conditions for simply testing myself for errors.
In this kind of usage I don't usually write down _all_ of the pre/post
conditions, but only those that I either feel shaky about or I believe
are important enough.

3) Unexpected Exceptions. I found this one to be one of the most
useful uses. My company uses CORBA. One of the problems with
CORBA is that the infrastructure catches all of the exceptions, via
catch(...). This is great(?) for production but very annoying at
testing time when you need to know about unhandeled exceptions
(since it masks any unhandled exception).
Solution: I use the EXCEPTIONAL condition to cause an assert
when an unexpected exception occurs (by simply using a "false"
condition).

>
> I am not trying to be a downer, more I am sharing my experience.
>
> There may be a place for this lib in the same regard as scope guards are
> used. Scope guards are nice when you need them, but you don't need them
> everywhere....
>
>
>
>
> > -----Original Message-----
> > From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]
> > On Behalf Of Jarl Lindrud
> > Sent: Sunday, April 17, 2005 11:47 AM
> > To: boost_at_[hidden]
> > Subject: [boost] Re: Proposal: Design by Contract / Pre
> > &Postconditionslibrary
> >
> > Yariv Tal <yariv_tal2003 <at> hotmail.com> writes:
> >
> >
> > > Do you check at compile time that the used gave all of the variables
> > > participating in the expression or do you just let the user state
> which
> > > variables they want to be displayed in the error message?
> >
> > The user just states which variables he'd like to see printed, if the
> > condition
> > were to fail, and its fine not to specify any variables at all.
> >
> > >
> > > One thing though, I didn't see any handling of disabling testing
> post
> > > conditions when
> > > an exception is thrown.
> > > Did I miss something?
> >
> > No you didn't... guilty as charged :)
> >
> > >
> > > >
> > > > Since these macros are part of the function implementation, maybe
> one
> > > shouldn't
> > > > borrow the name "Design By Contract", since that implies a
> contract
> > > external to
> > > > the function. Proper DbC contracts need to be stated at the level
> of
> > > function
> > > > declarations, and would apply to overrides in derived classes as
> well.
> > > Point taken.
> > > Originally I was hoping to add invariants etc., but I didn't get to
> it.
> > > Of course, even with invariants it will still be more at the
> function
> > level.
> > > In general, I think there's a lot to do (temporal invariants as in
> > "keystone
> > > ", for example)
> > > and since it is so useful (a fact I discover every time a condition
> in
> > my
> > > code is invalidated)
> > > it think, IMHO, it should be a library for all to use and for many
> to
> > > contribute to.
> >
> > Agreed. Formalizing the PRECONDITION and POSTCONDITION macros would be
> > quite
> > useful, I think. But I wouldn't be too worried about trying to emulate
> > DbC,
> > that's a different concept altogether.
> >
> > /Jarl.
> >
> >
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>