Re: [boost] Looking for thoughts on a new smart pointer:shared_ptr_nonnull

Subject: Re: [boost] Looking for thoughts on a new smart pointer:shared_ptr_nonnull
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-10-10 18:12:34

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.