On 08/10/13 05:56, 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.
It's more general for a non-null pointer to describe the situation of non-null, than it is for the smart pointer to describe that situation and also do validation and potentially throw an arbitrary exception.
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).
If a previous result can fail, that result should be checked during the normal flow of the code. The programmer can then decide to branch or throw an exception, or abort or whatever he wants to do. You asked for opinions on non-null shared_ptr; it will be more generic, more composable and more useful if it doesn't also validate its argument and throw. The throwing behaviour can be added with a factory or a new type that composes this type, but it can't be removed. Ben