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: Pete Bartlett (pete_at_[hidden])
Date: 2013-10-04 18:10:44

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.
>
>> 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.

It is a relief to me that this is at least a subject of debate. I've read
the doctorine of asserts-on-pre-condition-failure for years on
forums/mailing lists, but never felt I can truly apply it in the systems I
have to deal with in real-life. 

Even if you concentrate on errors that could only be possibly be client
programmer error (as opposed to some weird environmental condition), it
rarely seems to be the case that the purist view "this single thing is wrong
so I can't trust _anything_ about my system, I have to end now, leave no
logging entrails, or give the client any chance to do any sort of salvage"
is the least-worst practical option. For me it is often the case that I do
have to assume some entire subsystem is invalid (e.g. one entire thread) and
have to throw a long way out (and, yes, execute destructors), but at least
soldier on or shut down relatively cleanly. If the destructors go bad in
this teardown then you end up calling abort due to the double-throw rule..
but hey that's no worse than asserting in the first place! 

As Thorsten says, devs are not infallible and customers don't like their
apps going bang.. Is my experience atypical?

Pete