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: Daniel James (daniel_at_[hidden])
Date: 2013-10-05 10:32:12

On 5 October 2013 14:49, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Pete Bartlett 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.
>
> There should be code between the two ensuring that the output of
> one doesn't violate the precondition of the other.

Just because there should be something, doesn't mean that there is.
People get this wrong all the time.

>> >> 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.
>
> If the code isn't checking for precondition violations, then it
> isn't ready to handle the exception, either.  If the programmer
> knows enough to handle the exception, then s/he knows enough to
> prevent it.

If you avoid excessive state and make good use of RAII, handling
exceptions is generally easier than avoiding bugs. Of course, that
does depend on what sort of software you're writing. And if the
programmer knows enough to avoid using a null pointer, then they why
would they use a class that ensures that a pointer isn't null.

Anyway, there are two separate issues here:

1) Whether or not the check should always be present.
2) What should happen when the check fails.

My strongest argument concerns the first point, and I hope it's
clearly the one I'm more concerned with. So I'm finding a bit odd that
it's not really being addressed by most responses.