|
Boost : |
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:10:45
On 5 October 2013 09:40, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk