Subject: Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-10-07 17:56:09
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk