Re: [boost] [contract] invariant checking after destructor throw

Subject: Re: [boost] [contract] invariant checking after destructor throw
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-09-03 20:52:22

On Mon, Sep 3, 2012 at 1:47 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Tue Aug 28 2012, Andrzej Krzemienski <akrzemi1-AT-gmail.com> 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).
>
> It's not undefined behavior.  The members and bases are not yet
> destroyed.  Otherwise, how would you release any resources held in
> mmebers?
>
>> 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.
>
> This is still a good question.

Yes, it's a good question and it would seem that N1962 specifies only
member functions (not destructors) abnormal exit:

``
3. It (the class invariant) is called implicitly from public

a. pre- and postconditions,
b. constructors,
    call the class invariant before the postcondition,
c. destructors,
    call the class invariant before the destructor body.
d. member functions that exit abnormally via an exception [5]

[5]     To ensure that the function gives the basic guarantee of
exception-safety.
''

I think checking invariants on destructor abnormal exit is a defect of
the current implementation (btw, trivial to fix) but I reserve to
double check with all the references that I looked at when
implementing the lib before fixing it.

Thanks,
--Lorenzo