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 "function try blocks" in constructor and destructor definitions. This is what I mean. http://msdn.microsoft.com/en-us/library/e9etx778%28v=vs.71%29.aspx http://www.gotw.ca/gotw/066.htm
I have implemented support for function-try-blocks and also for exception specifications. For example: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont... 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 specifications. Syntax: 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. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/contract-syntax-redesign-tp3563993p383072... Sent from the Boost - Dev mailing list archive at Nabble.com.