[Contract] noexcept and custom contract violation handlers
Hi, I have just realized that there is an interesting interaction between "noexcept" and Contract Programming framework. Not only Lorenzo's library, but even if contracts were a language feature. N3248 ("noexcept prevents library validation", http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf) recommends that functions with any preconditions should not be declared noexcept(true) in case someone wants to report precondition failures via exceptions. If preconditions become part of declaration syntax, declaring both precondition and noexcept(true) could (and should?) be recognized as compile-time error. But now also invariants and postconditions come into play: if a function declares a postcondition, or our class defines an invariant, should we be allowed to declare our function noexcept? What if someone wants to report an invariant or postcondition failure via special exception? (I do not have a good answer for it.) Regards, &rzej
On Thu, Aug 30, 2012 at 5:36 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
Hi, I have just realized that there is an interesting interaction between "noexcept" and Contract Programming framework. Not only Lorenzo's library, but even if contracts were a language feature. N3248 ("noexcept prevents library validation", http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf) recommends that functions with any preconditions should not be declared noexcept(true) in case someone wants to report precondition failures via exceptions. If preconditions become part of declaration syntax, declaring both precondition and noexcept(true) could (and should?) be recognized as compile-time error.
But now also invariants and postconditions come into play: if a function declares a postcondition, or our class defines an invariant, should we be allowed to declare our function noexcept? What if someone wants to report an invariant or postcondition failure via special exception? (I do not have a good answer for it.)
I see... I think it should be OK however if you don't report contract failures using exceptions (but you just let the program terminate in case of a contract failure). Ideally, if you start throwing from the contracts and you also use noexcept, the lib will give you a compile-time error. I'll note this issue and I'll explore it fully when I start supporting C++11. Thanks, --Lorenzo
on Thu Aug 30 2012, Andrzej Krzemienski <akrzemi1-AT-gmail.com> wrote:
Hi, I have just realized that there is an interesting interaction between "noexcept" and Contract Programming framework. Not only Lorenzo's library, but even if contracts were a language feature. N3248 ("noexcept prevents library validation", http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf) recommends that functions with any preconditions should not be declared noexcept(true) in case someone wants to report precondition failures via exceptions.
This is bad advice and should be ignored. Exceptions and preconditions have no inherent relationship, exceptions are not a good tool for handling precondition failures, and nothing should be done to link them. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
2012/9/2 Dave Abrahams <dave@boostpro.com>
on Thu Aug 30 2012, Andrzej Krzemienski <akrzemi1-AT-gmail.com> wrote:
Hi, I have just realized that there is an interesting interaction between "noexcept" and Contract Programming framework. Not only Lorenzo's library, but even if contracts were a language feature. N3248 ("noexcept prevents library validation", http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf) recommends that functions with any preconditions should not be declared noexcept(true) in case someone wants to report precondition failures via exceptions.
This is bad advice and should be ignored. Exceptions and preconditions have no inherent relationship, exceptions are not a good tool for handling precondition failures, and nothing should be done to link them.
I agree in principle; however, N3248 provides one example that cannot be that quickly dismissed: testing if your library defined (and verified) enough preconditions. Also, one other concern is that since Contract Programming framework provides customization functions, like set_postcondition_broken, people will likely choose to configure the library to throw on contract breakage. They will define a cool exception type, like BrokenContract, and throw it. If not for any other reason, then because languages like D do it; or because they are afraid of std::terminate (more than they are afraid of writing incorrect code). Although, you could say that in this case termination from precondition breakage will be replaced with termination from noexcept violation, which is what people deserve if they break contracts. Regards, &rzej
On 02.09.2012 21:40, Andrzej Krzemienski wrote:
2012/9/2 Dave Abrahams <dave@boostpro.com>
This is bad advice and should be ignored. Exceptions and preconditions have no inherent relationship, exceptions are not a good tool for handling precondition failures, and nothing should be done to link them. I agree in principle; however, N3248 provides one example that cannot be that quickly dismissed: testing if your library defined (and verified) enough preconditions. googletest, just as an example, provides death tests. Set Contract to terminate on violation (as it should) and run them.
Sebastian
On Mon, Sep 3, 2012 at 12:54 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 02.09.2012 21:40, Andrzej Krzemienski wrote:
2012/9/2 Dave Abrahams <dave@boostpro.com>
This is bad advice and should be ignored. Exceptions and preconditions have no inherent relationship, exceptions are not a good tool for handling precondition failures, and nothing should be done to link them.
I agree in principle; however, N3248 provides one example that cannot be that quickly dismissed: testing if your library defined (and verified) enough preconditions.
googletest, just as an example, provides death tests. Set Contract to terminate on violation (as it should) and run them.
Just to be 100% clear, if you don't set anything, Contract will terminate on violation--that's default behavior "out of the box", you have to set stuff to throw, exit, abort, ignore, or do whatever else you might want to do instead of termination. Thanks, --Lorenzo
participants (4)
-
Andrzej Krzemienski -
Dave Abrahams -
Lorenzo Caminiti -
Sebastian Redl