Subject: Re: [boost] [contract] invariant checking after destructor throw
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-08-28 20:30:47
On Tue, Aug 28, 2012 at 1:02 PM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
> I have found a potential issue while reading the documentation. (The
> documentation is very good BTW). It says that the non-static invariant is
> still checked if object's destructor throws an exception. Am I reading it
> right? If so, I believe this is not correct. I have two problems with it:
> 1. According to the standard, an object is considered destroyed (its
> life-time has ended) when its destructor *starts*. Even if it throws an
> exception, it is considered destroyed, so accessing its members (in order
> to check for the invariant) may be illegal (an undefined behavior).
> 2. Why such an object (that threw on destruction) would need to preserve
> the invariant? You cannot access it or use it or even destroy it the second
> time, because it has already been destroyed. No-one will notice it anyway.
> Or am I missing something?
I think you are right... I swear I read somewhere that destructor
abnormal exit (on throw) should still check class invariants but I
just double checked N1962 and N1613, that doesn't seem to be the case.
On the contrary, N1962 says:
3. It (the class invariant) is called implicitly from public
a. pre- and postconditions,
call the class invariant before the postcondition,
call the class invariant before the destructor body.
d. member functions that exit abnormally via an exception 
 To ensure that the function gives the basic guarantee of exception-safety.
Which is consistent with your argument... Also, if the standard says
no object after destructor starts then invariants apply no more.
In any case, this is trivial to fix. I entered a ticket for it:
I'll double check a few sources (N-papers, standard, and Eiffel) and
if this is indeed a bug, consider it fixed.
Thanks for catching this!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk