Re: c++ question regarding exception safety
* James Kanze:
On 8 mar, 16:34, "Alf P. Steinbach" <al...@start.no> wrote:
A good approach might be to study the Java example I linked
to. And I mean really study it. For example, try to answer
these questions:
* What is the class invariant in that example?
* Exactly how does the lack of deterministic destruction, in
that example, influence the choice of class invariant?
OK. But the first thing I see is:
public DbConnection () {
//build a connection and assign it to a field
//elided.. fConnection =
ConnectionPool.getInstance().getConnection();
}
That's the [constructor], and the interesting part---the essential
part, in fact, has been elided. If the constructor throws an
exception if it cannot establish the invariants, then there can
be no zombie.
The class invariant may be a bit easier to see by examining the following (Java)
code snippet from the article:
public void destroy() throws SQLException {
if (fIsDestroyed) {
return;
}
else{
if (fConnection != null) fConnection.close();
fConnection = null;
//flag that destory has been called, and that
//no further calls on this object are valid
fIsDestroyed = true;
}
}
Implied by that code:
boolean invariantHolds()
{
return
fIsDestroyed ||
(fConnection == null || isValidConnection( fConnection ));
}
The possibility of (fConnection == null) just complicates the picture. It seems
to be due to the author not being sure whether getConnection() signals failure
by returning null or throwing an exception. Another possibility might be that
the author envisions some closeConnection() method in addition to destroy().
If we assume that getConnection() throws on failure, and there's no additional
closeConnection() method, then things can become more clear.
For in that case fConnection can't be null and the class invariant reduces to
boolean invariantHolds()
{
return
fIsDestroyed || isValidConnection( fConnection );
}
which can be rewritten, for clarity, as
boolean isZombie() { return fIsDestroyed; }
boolean nonZombieInvariantHolds() { return isValidConnection( fConnection ); }
boolean invariantHolds() { return isZombie() || nonZombieInvariantHolds(); }
I hope you're with me so far in this analysis, because there's no point going
further without agreeing on the above conclusion. Namely, that we have a
constructor that signals failure (not able to establish class invariant) by
throwing, that we have something that can reasonably be called a class invariant
that holds for any constructed object (I find it more clear to refer to that
something as a /meta/ class invariant, and reserve plain "class invariant" for
what the function nonZombieInvariantHolds() checks), and yet we have a zombie.
Point of possible contention: where fIsDestroyed might be set to true, and why.
Hint: it's not in the constructor.
In passing, yes, lack of exception support is also a common cause of zombies.
It can be worked around by always allocating objects dynamically, or via dynamic
allocation-like syntax. Which is a heavy price to pay in C++.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?