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