Re: boost::throw_exception potential changes

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-02-02 22:02:46

On 2/3/22 00:58, Emil Dotchevski via Boost wrote:
> On Wed, Feb 2, 2022 at 1:49 PM Andrey Semashev via Boost <
> boost_at_[hidden]> wrote:
>>
>> On 2/2/22 22:34, Andrey Semashev wrote:
>>> On 2/1/22 07:48, Peter Dimov via Boost wrote:
>>>> Currently, `boost::throw_exception(x)` automatically throws
>>>> an exception derived from `x` that (1) injects a boost::exception
>>>> base class if there's none, and (2) injects a base class that enables
>>>> boost::exception_ptr support (boost::current_exception and
>>>> boost::rethrow_exception.)
>>>>
>>>> This is convenient, but the downside is the amount of generated
>>>> code, e.g. https://godbolt.org/z/5T8T8GEqP (422 lines) compared
>>>> to https://godbolt.org/z/1zr1odf7n (36 lines.)
>>>>
>>>> This is not the end of the world as this code is only generated once
>>>> per exception type, not on every call to throw_exception, but it's
>>>> still unpleasant to see.
>>>>
>>>> It so happens that boost::exception_ptr has recently acquired the
>>>> ability to work under C++11 without the need for the supporting
>>>> base class, by using the standard std::exception_ptr infrastructure.
>>>> So if we also remove the automatic injection of boost::exception
>>>> as a base class, and ask users to derive their exceptions from it if
>>>> they desire having it as a base, it's possible to simplify
>>>> boost::throw_exception considerably.
>>>
>>> I would like to ask to not do this, as this is a breaking change and I
>>> have written code (outside Boost) that relies on BOOST_THROW_EXCEPTION
>>> and boost::exception. That is, I expect that an exception thrown by
>>> BOOST_THROW_EXCEPTION triggers `catch (boost::exception& e)` handler,
>>> where I may augment it with additional info before rethrowing. I also
>>> think one could use dynamic_cast to boost::exception to the same effect,
>>> and that would also break after such a change.
>>>
>>> If some lightweight throwing mechanism is needed (of which I'm not
>>> convinced), I would prefer that to be a new API.
>>
>> If we want to optimize code size, I would rather preferred if there was
>> an API that allows to move exception construction into a function.
> 
> You could move the throw statement itself into a function, so instead of a
> throw statement the compiler would generate a call to a function that
> throws. But I remain unconvinced that the overhead matters.

Sure, but that requires a lot of work, since every throw site needs to
be modified in such way. Whereas BOOST_THROW could be nearly a drop-in
replacement for BOOST_THROW_EXCEPTION or raw throw and still be more
efficient than the former.