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. 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. The motivation for the nullness tests in the original example was to clean up partly-constructed objects. Another Look At the Destructor/Dispose Codeįinally, let’s return to each key line of code one more time: // C++ 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.

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.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.Here are the major idiomatic ways in each language to use an Gadget object in an exception-safe way: // C++ callerĬonsider the two cases where an exception can occur: Next, let’s see how these semantics are actually enforced, whether by language rules or by convention, on the calling side in each language. But let’s leave that aside for now to explore the more general issue. 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 or an equivalent smart pointer type that owns the object. Incidentally, it also means that the Gadget constructor isn’t exception-safe, because it and only it can clean up resources it might leak. 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. In particular, if Gadget’s constructor throws, it means that the Gadget object wasn’t created and never existed. 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++. Hence, destructors/disposers only run on successfully constructed objects. 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. A destructor/disposer conceptually turns an object back into raw memory.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.

An object’s lifetime doesn’t begin until its constructor completes successfully. A constructor conceptually turns a suitably sized chunk of raw memory into an object that obeys its invariants.The fundamental principles behind the answer is the same in C++, C#, and Java: 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. or just “w = null ” if Widget isn’t disposable or just “w = null ” if Widget isn’t IDisposable … eliding other mechanics, eventually calls: 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 I just received the following question, whose answer is the same in C++, C#, and Java.

Java constructor exception