#66 check no class invariant if destructor throws

[Lorenzo Caminiti]

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 and that doesn't seem to be the case. On the contrary, N1962 says:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1962.html#class-invariants

``
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.

Which is consistent with your argument... if the standard says no object after destructor starts then invariants apply no more.

In any case, this if trivial to fix.
I'll double check a few sources (N-papers, standard, and Eiffel) and if this is indeed a bug, fix it.

[Lorenzo Caminiti]

• status changed from new to accepted
• milestone set to 1.0.0

[Lorenzo Caminiti]

See email thread (and Dave's reply) for clarity but this is still a defect...