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

On 5 October 2013 09:40, Andrey Semashev wrote:

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.

I didn't say it wasn't a bug. I said it doesn't mean that there's anything wrong with the global state.

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.

But an asserts don't crash in release mode, since they are disabled. The code continues until later - when it could be more damaging - especially if it affects permanent state.