Re: [boost] Re: i/o state savers exception-safety

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-01 08:52:28

From: "Daryle Walker" <darylew_at_[hidden]>

> on 7/30/02 10:12 AM, David Abrahams at dave_at_[hidden] wrote:
>
> > I just noticed this in the docs for i/o state savers:
> >
> > 1.. When a new success state is activated for exception watching, an
> > exception is thrown if that state is already active. This could mean
that
> > the destructor of this class template may throw.
> >
> > What steps does the class take to prevent termination during exception
> > unwinding? If none, I think it's unacceptable. If it does take steps,
they
> > need to be spelled out; the statement above is too alarming by itself.
>
> It takes no precautions.  You have to take the risk.  I'm not sure that
> anything can, or should, be done.
>
> There is a standard function to check if we are already handling an
> exception, but I heard that many don't think it's useful.  Worse, the
> function is not implemented on some compilers (like mine!).
>
> > Also, I wonder about the potential for throwing an exception when
stream
> > state is restored in general. If an i/o operation fails, and the saver
> > resets the stream state while it is being destroyed, can that operation
> > fail? If it fails, what happens?
>
> I think the stream state (re)setting is just bit-twiddling, so that
should
> be fail-free.  If an exception is generated, then that exception will
throw,
> or another (e.g. std::bad_alloc) if that I/O exception object fails to be
> constructed.

IMO this response is much too vague to be appropriate for Boost. You should
be sure about what the standard says on stream state re-setting, and you
should understand what the standard says about uncaught_exception() to see
if its use is appropriate here rather than appealing to what "many don't
think" about its usefulness. In this case it might even make sense just to
eat any exceptions that occur during destruction with catch(...){}, but you
need to do the careful analysis to decide what is appropriate. Allowing
destructors to throw during unwinding is IMO simply unacceptable.

I want to be able to recommend this library to people, but without a much
more rigorous treatment of the exception-safety issues I'll have to
recommend they avoid it.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com