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: Jeff Flinn (jeffrey.flinn_at_[hidden])
Date: 2013-10-08 09:59:12

On 10/7/2013 5:56 PM, Gavin Lambert wrote:
> On 10/7/2013 11:41 PM, Quoth Ben Pope:
>> The point is still that validating at runtime by throwing an exception
>> is not good enough.  If the programmer wants to use a non-null smart
>> pointer, he wants to only ever pass in a non-null pointer.  Detecting a
>> null-pointer inside the construction of the smart pointer is already too
>> late; the programmer thought it was non-null, so in essence, he has no
>> idea what the code is doing... Whatever it *is* doing may not be
>> undefined, but it is most certainly wrong.  How do you recover at
>> runtime from a program that does not do what you thought it did?
>
> It depends on the program, which is why recovery has to be in the hands
> of the program.
>
> Maybe the pointer was null because an earlier operation transiently
> failed, in which case it could be retried, or the operation abandoned
> and the next operation attempted (think of a web server or similar --
> just because processing of one request got it into a bad state doesn't
> mean that it can't successfully process other requests, since each
> request operates on independent state).

Either the factory function returning the pointer, or the client using 
the pointer is missing it's post-condition check and not appropriately 
dealing with it. The point is someone upstream is failing to live up to 
it's contract responsibilities. That's where the check and handling 
should be. The responsibility should not be foisted upon 
shared_non_null. That said, shared_non_null could be wrapped by a 
function that checks the pointer and handles the null case 
appropriately: throwing, returning a boost::optional<shared_non_null>, 
etc. IIRC, there was a proposed library providing such functionality.

Jeff