On Tue, Jun 13, 2017 at 6:00 PM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 14/06/2017 12:29, Emil Dotchevski wrote:
Except it won't work, you've uncovered an omission in the Noexcept API. The 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, or maybe instead I can add a member function tr.throw_() which flags the error 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 catch_
? 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 propagate.
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:
init_something(); try { // do something that might throw } catch (...) { cleanup_something(); throw; } 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 else return throw_(); It's just the case with try_ that doesn't work right now, but yes it has to be fixed, it is essential.