Re: [boost] [thread] Questions about broken_promise

Subject: Re: [boost] [thread] Questions about broken_promise
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-07-29 05:29:41

On Mon, Jul 29, 2013 at 10:57 AM, Jonathan Wakely
<jwakely.boost_at_[hidden]>wrote:

> On 28 July 2013 22:24, Klaim - Joël Lamotte wrote:
> > I have a few questions concerning broken promises (exception):
> >
> > 1. is the broken_promise exception a standard, or future standard
> behaviour?
> > So far I assumed it wasn't because
> > http://en.cppreference.com/w/cpp/thread/promise/~promise
> > don't say anything about this and I only read about broken_promise
> > exceptions on Boost.Thread
> > documentation.
>
> Did you try searching the standard?
>
> If a std::promise with an associated shared state is destroyed before
> making the state ready it sets an exception of type std::future_error
> with an error condition of std::future_errc::broken_promise.
>
>
I didn't yet, thanks for pointing that.

> > I would like to know if I should expect the future standard library to
> have
> > the same concept.
> > I see no configuration macro to deactivate these exceptions. I don't want
> > to actually, but
> > if I'm correct that it's not standard or future standard, then it's
> > surprising that I can't setup
> > a standard-like setup.
>
> You're not correct.
>
>
Ok.

>
> future::has_value() is non-standard. You can use a timed-waiting
> function instead.
>
>
Yes, my real code doesn't do exactly that and is more like using .then().
I can't use time waiting functions in my case.

> > My question is: why is copy_exception necessary and why does it have to
> do
> > it this way?
>
> N.B. std::copy_exception was renamed make_exception_ptr before the
> final C++11 standard, I guess Boost didn't follow that change.
>
> How else do you create an exception_ptr that refers to an active
> exception object (i.e. one that has been thrown, so is created on
> whatever special stack the compiler uses for exceptions)?
>
>
I see.

>
> The library is following the standard, if your IDE flags that as an
> issue it's a problem with your IDE.
>

I believe then that's it's more a collaboration issue: the IDE doesn't
"flag" the exception thrown,
what it does is just log it by default in the debug console.
However, if you set the IDE to break each time any C++ exception is thrown,
then it will break in the throw in copy_exception() and current_exception().
So the IDE behave correctly, but have no way to know that these throw are
an implementation detail.
Just ignoring the breakpoint or setting the IDE to default (break only on
some specific throw and just log throws that are catch)
does work fine so I'll work this way instead for now.
It's only in some kind of debugging session that the throw in these
functions can be noisy.

Joel Lamotte