On 6 October 2013 12:04, Rob Stewart
If the exception is triggered by an unknown condition, such as you're advocating, then there can be no handler for it. It must, of necessity, unwind to the top. Code cannot rightly continue as if there had been no exception. In that case, there's little gained over an assertion, save for the possibility that other threads may be able to complete independent work.
later:
The likely outcome of failure in this regard, in a non-debug build, is a null pointer dereference elsewhere. Unchecked, that means a segfault. IOW, the problem will be found.
So you're saying that when it's an exception, it's triggered by an "unknown condition" not by a null, which is surely a known condition. But when there's no check it's known to be a null pointer that will be quickly dereferenced before anything bad might happen. Even if it's in a data structure, or in a container after hundreds of pointers which aren't null. And you're claiming that after an exception the code will continue as if there was no exception. Is that really what you do after catching an exception? But when there's no check, it will do the right thing and continue, which is course as if there was no exception, because there wasn't one. But that's okay now for some reason. Do you see why I don't find your argument persuasive?
The point of the proposed class is that, once (properly) instantiated, it's a signal to code that a null check is unnecessary, just as using a value or reference is.
No it isn't. The description was, "a variation on shared_ptr which is never allowed to be empty".