Subject: Re: [boost] [contract] syntax redesign
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-09-21 13:06:15
Andrzej Krzemienski wrote:
>> Comments are always welcome :)
> library growing at this pace. I would like to suggest two things. I could
> not see from the examples, if the library is capable of supporting
> try blocks" in constructor and destructor definitions. This is what I
I have implemented support for function-try-blocks and also for exception
specifications. For example:
Preconditions, postconditions, and class invariants are checked outside
function-try-blocks (N1962) and I do the same for exception specifications.
Therefore, both function-try-blocks and exception specifications only catch
exceptions thrown by the function body and not exceptions thrown by my
library implementation (if there is an internal library error) or by a
contract assertion failure*.
(*) As I mentioned a few times before, in case a contract assertion is not
checked to be true (because it is false or because the assertion checking
throws), my library calls the contract broken handlers which call
std::terminate (N1962). However, users can redefine the broken handlers to
do whatever they wish including throwing an exception. In this case (which
is not adviced and it is not the library's default behavior) the exception
thrown by the broken contract assertion will /not/ be caught by the
function-try-block (as per N1962) nor by the function exception
1) Exception specifications are specified within the contract macros because
they are part of the function declaration.
2) Function-try-blocks are specified outside the contract macros because
they are part of the function definition. The only exception of this rule is
for constructors with member initializers for which both the member
initializers and function-try-block are specified within the macros (even if
both the member initializers and the function-try-block are still part of
the constructor definition). This is a (small?) limitation of my library
which is caused by C++03 lack of delegating constructors and ultimately
causes the limitation that constructors with member initializers need to be
defined together with their declarations when the contract macros are used.
-- View this message in context: http://boost.2283326.n4.nabble.com/contract-syntax-redesign-tp3563993p3830729.html Sent from the Boost - Dev mailing list archive at Nabble.com.