Subject: Re: [boost] Noexcept
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-06-14 01:25:08
On Tue, Jun 13, 2017 at 6:00 PM, Gavin Lambert via Boost <
> On 14/06/2017 12:29, Emil Dotchevski wrote:
>> Except it won't work, you've uncovered an omission in the Noexcept API.
>> problem is that catch_<> will flag the error as handled, and in this case
>> you don't want that. I need to add another function similar to catch_<>
>> which only gets the error without handling it. Not sure what to call it,
>> maybe instead I can add a member function tr.throw_() which flags the
>> as unhandled.
>> (Related: if the original throw_ was a custom type not derived from
>>> std::exception, and catch<> is used to catch it as a std::exception and
>>> throw_ it again, can it still be caught later with a
>>> Does the answer depend on whether throw_() or throw_(e) was used?)
>> throw_() is a noop, except that it converts to anything for return
>> throw_(), returning throw_return<R>::value() where R is the return type of
>> the function.
> Ok, I assumed that throw_() was the equivalent of throw; ie. a way to flag
> a previously-caught exception as unhandled again so that it continues to
> If you're modelling this based on try-catch, that seems like essential
> functionality -- in code that wants to implement a sort of try-finally
> without using RAII classes it's not uncommon to see patterns like this:
> // do something that might throw
> catch (...)
> cleanup_something(); // if needed in the success case as well
Absolutely. The reason why this fell through the cracks is that with
Noexcept you could do this without a try_:
if( auto r=foo() )
//success, all good
It's just the case with try_ that doesn't work right now, but yes it has to
be fixed, it is essential.