On 10/11/2013 4:00 AM, Quoth Nevin Liber:
In general, destructors are written assuming the invariants of the class hold on entry to the destructor.
And..? If the constructor of an object throws, its destructor is not invoked. So all destructors that are called should still have good invariants. It's only if you *don't* throw from the constructor that you'll have a problem, because now you *do* have an object with an invalid invariant. (And if "my internal pointer is non-null" is not an invariant of this class, then it has no reason to exist.)
In order for what you say about stack unwinding to be true, you have to assume that the null pointer isn't due to a broken invariant somewhere else. Where is your evidence that no other object or program invariants are broken?
Where is your evidence that they are? Given that this must (by definition) be the first time that this particular pointer has been assigned to a "must be non null" smart pointer object, everything else higher up the call stack either must not be using the pointer or must be ok with the idea that it could be null, otherwise the problem would have been encountered earlier.
Data corruption is a far worse user experience.
Granted. But there shouldn't be any of that here, unless the programmer doesn't write their higher-level catch handler properly.