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

Subject: Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-10-05 04:40:44

On Friday 04 October 2013 21:09:02 Daniel James wrote:
> On 4 October 2013 17:45, Eric Niebler <eniebler_at_[hidden]> 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.