|
Boost : |
Subject: Re: [boost] Noexcept
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-06-14 01:00:14
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_<custom_error>?
>> 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".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk