Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull

On Friday 04 October 2013 21:09:02 Daniel James wrote:

On 4 October 2013 17:45, Eric Niebler wrote:

...

On 10/4/2013 9:20 AM, Matt Calabrese wrote:

...

but I definitely am against an exception for this type of programmer error.

This is the crux of it. If this condition really does represent a programmer error (and IMO in this case it does), then Matt is right. Throwing is wrong. Programmer error == bug == your program is already in some weird state. Continuing by throwing an exception and executing an arbitrary amount of code is not good.

I don't think this is always the case. For example, unexpected output from a parser should not be an indicator of an error in the global state.

I agree with Eric. If the unexpected output is the result of an error in the parser implementation then this is a bug in the parser and no exception will fix that. If this is the result of invalid input from the environment then it should be detected by the parser and indicated with an exception or other means. Again, if the parser doesn't do that, it is a bug in the parser. Bottom line: only throw exceptions as a result of abnormal behavior of the environment of the program, and not as a result of internal bugs.

...

Precondition violations ==> assertions. Use BOOST_ASSERT. That gives people a way to hook the behavior while giving a sane default.

If throwing an exception when this is null is a bad idea, then not checking in release mode is surely a terrible one.

I don't think so. If not checking makes it crash and burn then let it be that way. The sooner it crashes, the sooner you'll fix the bug. Exceptions, on the other hand, even if logged, tend to be ignored until it is apparent that something goes on wrong. This may be much much later than when the problem have occurred and makes debugging much harder.