Boost logo

Boost :

Subject: [boost] [contract] oldof failure not in N1962?
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-07-18 13:58:49


Hello all (and especially N1962 authors),

As far as I can see, N1962 does not say what to do in case of a failure
while evaluating and copying an oldof expression. For example, what shall
Contract Programming do if there is a memory error while taking a copy of
size() to later check the following postcondition?

    size() == oldof size() + 1

Given that oldof copies are taken just after preconditions are checked and
before the body is executed, I am tempted to treat the oldof failure as a
precondition failure and call the precondition_broken handler. An
alternative would be to to treat the oldof failure as if it happened within
the body. However, in this case the body will raise more errors (e.g., throw
more exceptions) that it will raise without the oldof contracts so I don't
think this is a good approach.

In summary:
1) oldof expressions belong to the contract therefore I think oldof failures
should result in calling one of the contract failure handlers
(precondition_broken or postcondition_broken).
2) Given that eventual oldof failures happen before the body is executed
(and just after the preconditions are checked), I think precondition_broken
should be called (instead of postcondition_broken) in case of an oldof
failure.

The counter argument is that precondition failures indicate a bug in the
caller. However, oldof failures indicate a system-level exception in the
code that programs the program-- oldof failures are not bugs in neither the
caller (precondition_broken) nor in the body implementation
(postcondition_broken)... but if you follow this argument, you need to give
up 1)...

What do you think?

Thank you.
--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/boost-contract-oldof-failure-not-in-N1962-tp3676021p3676021.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk