RE: [boost] Stronger exception safety guarantee for smart_ptr.res et()

From: scleary_at_[hidden]
Date: 2001-06-19 19:07:58

> > <Steve Cleary>
> >   2) It makes throwing *any* exception a risky business -- if there's an
> > object with a throwing destructor on the stack, your program's blown
away.
> 
> <Vesa Karvonen>
> This is a valid issue. However in this case we are considering the
run-time
> behavior of smart pointer reset(). reset() results in deleting a heap
object.
> A program can actually survive from the situation which we are
considering.

Sorry - I was thinking of the destructor of a smart pointer on the stack.
If it could throw, that opens up issue 2, above.

> > > <Vesa Karvonen>
> > > I think that the current nothrow guarantee of smart pointer reset()
(including
> > > std::auto_ptr and boost::shared_ptr) gives a false sense of exception
safety,
> > > because it simply doesn't guarantee any consistent programmatically
detectable
> > > effect - in the case that an exception is actually throw.
>
> > <Steve Cleary>
> > Neither does any other code producing undefined behaviour.  Hence the
name,
> > "undefined"...
> 
> <Vesa Karvonen>
> The last time I checked, everything does not turn undefined in C++ at the
> point the first exception is thrown - don't tell me they've changed
this...

Clarification: (I know you already know this, but this is what I was meaning
to say above): if you throw an exception from a destructor of any object
used to instantiate std::auto_ptr, the behaviour is undefined.

> > <Vesa Karvonen>
> > I'll have to see about what can be done about the documenting aspect. As
I've
> > explained earlier, I'm developing a resource library that could make use
of
> > this feature. If it turns out that the feature is too difficult to
document,
> > then I should probably leave it out.
> 
> <Dave Abrahams>
> I don't think it's difficult to document. The problem is that documenting
it
> complicates the world for users of the library. They no longer can rely on
> unconditional nothrow behavior from certain operations.

Specifically, destructors.

I agree with Dave -- this is a fine idea for a QOI guarantee, but I'm wary
of documenting the ability to have throwing destructors.  I suppose I could
go along with this if we put a clause in the effect: that if the user object
doesn't throw in its destructor, the smart pointer won't throw in its
destructor or reset.

As far as a resource library goes, my first version had throwing
destructors.  I quickly ran into the problems that others have found.  My
next version had a "close" function which would free the resource, allowing
errors to propogate, but have the destructor free the resource, ignoring
errors.  I set up all my resources this way, but after having used it for a
few years, I noticed that I never actually use the throwing close functions
-- at least with my programs, I can't think of a single time that my program
could do anything if a resource *wasn't* freed.  So, with my third version,
I just ignore all resource free errors.

Then again, that's just my programs, which are system critical (running
plant operations, etc.) on Win32 (yuck) -- all they can do is throw a
message in a log; what else?  And under *no* condition can they stop running
-- and, yes, in my code I have a hard-and-fast rule of no throwing
destructors, ever.  Maybe other programs could do something with a failed
destructor, I don't know.

        -Steve