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 You might argue (correctly) that RAII is better for this, but the pattern still exists. And it's sometimes used for other things, such as logging, or where the cleanup has to occur in a particular order and you don't want to rely on the order that destructors are called.
throw_(my_error()) will inject std::exception as a base if my_error doesn't already derive from it. I read that; I was wondering how it handled rethrows. Which I guess the answer in the current state is "it doesn't".