Hi Brian, "Brian Braatz" <brianb@rmtg.com> wrote in message news:7770D1D3403FEB4F9C05C20A923136CC94891C@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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jarl Lindrud Sent: Sunday, April 17, 2005 11:47 AM To: boost@lists.boost.org 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: