I just received the following question, whose answer is the same in C++, C#, and Java.
Question: In the following code, why isn’t the destructor/disposer ever called to clean up the Widget when the constructor emits an exception? You can entertain this question in your mainstream language of choice:
// C++ (an edited version of the original code
// that the reader emailed me)
class Gadget {
Widget* w;
public:
Gadget() {
w = new Widget();
throw new exception();
// … or some API call might throw
};
~Gadget() {
if( w != nullptr ) delete w;
}
}; |
// C# (equivalent)
class Gadget : IDisposable {
private Widget w;
public Gadget() {
w = new Widget();
throw new Exception();
// … or some API call might throw
};
public void Dispose() {
// … eliding other mechanics, eventually calls:
if( w != null ) w.Dispose();
// or just “w = null;” if Widget isn’t IDisposable
}
}; |
// Java (equivalent)
class Gadget {
private Widget w;
public Gadget() {
w = new Widget();
throw new Exception();
// … or some API call might throw
};
public void dispose() {
if( w != null ) w.dispose();
// or just “w = null;” if Widget isn’t disposable
}
}; |
Interestingly, we can answer this even without knowing the calling code… but there is typical calling code that is similar in all three languages that reinforces the answer.
Construction and Lifetime
The fundamental principles behind the answer is the same in C++, C#, and Java:
- A constructor conceptually turns a suitably sized chunk of raw memory into an object that obeys its invariants. An object’s lifetime doesn’t begin until its constructor completes successfully. If a constructor ends by throwing an exception, that means it never finished creating the object and setting up its invariants — and at the point the exceptional constructor exits, the object not only doesn’t exist, but never existed.
- A destructor/disposer conceptually turns an object back into raw memory. Therefore, just like all other nonprivate methods, destructors/disposers assume as a precondition that “this” object is actually a valid object and that its invariants hold. Hence, destructors/disposers only run on successfully constructed objects.
I’ve covered some of these concepts and consequences before in GotW #66, “Constructor Failures,” which appeared in updated and expanded form as Items 17 and 18 of More Exceptional C++.
In particular, if Gadget’s constructor throws, it means that the Gadget object wasn’t created and never existed. So there’s nothing to destroy or dispose: The destructor/disposer not only isn’t needed to run, but it can’t run because it doesn’t have a valid object to run against.
Incidentally, it also means that the Gadget constructor isn’t exception-safe, because it and only it can clean up resources it might leak. In the C++ version, the usual simple way to write the code correctly is to change the w member’s type from Widget* to shared_ptr<Widget> or an equivalent smart pointer type that owns the object. But let’s leave that aside for now to explore the more general issue.
A Look At the Calling Code
Next, let’s see how these semantics are actually enforced, whether by language rules or by convention, on the calling side in each language. Here are the major idiomatic ways in each language to use an Gadget object in an exception-safe way:
| // C++ caller
{
Gadget myGadget;
// do something with myGadget
} |
| // C# caller
using( Gadget myGadget = new Gadget() )
{
// do something with myGadget
} |
| // Java caller
Gadget myGadget = new Gadget();
try {
// do something with myGadget
}
finally {
myGadget.dispose();
} |
Consider the two cases where an exception can occur:
- What if an exception is thrown while using myGadget — that is, during “do something with myGadget”? In all cases, we know that myGadget’s destructor/dispose method is guaranteed to be called.
- But what if an exception is thrown while constructing myGadget? Now in all cases the answer is that the destructor/dispose method is guaranteed not to be called.
Put another way, we can say for all cases: The destructor/dispose is guaranteed to be run if and only if the constructor completed successfully.
Another Look At the Destructor/Dispose Code
Finally, let’s return to each key line of code one more time:
// C++
if( w != nullptr ) delete w; |
// C#
if( w != null ) w.Dispose(); |
// Java
if( w != null ) w.dispose(); |
The motivation for the nullness tests in the original example was to clean up partly-constructed objects. That motivation is suspect in principle — it means the constructors aren’t exception-safe because only they can clean up after themselves — and as we’ve seen it’s flawed in practice because the destructors/disposers won’t ever run on the code paths that the original motivation cared about. So we don’t need the nullness tests for that reason, although you might still have nullness tests in destructors/disposers to handle ‘optional’ parts of an object where a valid object might hold a null pointer or reference member during its lifetime.
In this particular example, we can observe that the nullness tests are actually unnecessary, because w will always be non-null if the object was constructed successfully. There is no (legitimate) way that you can call the destructor/disposer (Furthermore, C++ developers will know that the test is unnecessary for a second reason: Delete is a no-op if the pointer passed to it is null, so there’s never a need to check for that special case.)
Conclusion
When it comes to object lifetimes, all OO languages are more alike than different. Object and resource lifetime matters, whether or not you have a managed language, garbage collection (finalizers are not destructors/disposers!), templates, generics, or any other fancy bell or whistle layered on top of the basic humble class.
The same basic issues arise everywhere… the code you write to deal with them is just spelled using different language features and/or idioms in the different languages, that’s all. We can have lively discussions about which language offers the easiest/best/greenest/lowest-carbon-footprint way to express how we want to deal with a particular aspect of object construction, lifetime, and teardown, but those concerns are general and fundamental no matter which favorite language you’re using to write your code this week.
Sutter’s Mill 