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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk