Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)

Subject: Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-03-23 04:05:42

Emil Dotchevski wrote:

> On Tue, Mar 22, 2011 at 1:38 AM, Vladimir Prus
> <vladimir_at_[hidden]> wrote:
>> Emil Dotchevski wrote:
>>
>>> On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak
>>> <robert.kawulak_at_[hidden]> wrote:
>>>> >From Boost Users ML:
>>>>
>>>>> From: Hochhaus, Andrew
>>>>> I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++
>>>>> -fno-exceptions flag. However, it appears that some spots in boost
>>>>> library code:
>>>>>
>>>>> a) throw exceptions with the "raw" throw keyword [instead of
>>>>> BOOST_THROW_EXCEPTION or boost::throw_exception]
>>>>> b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
>>>>
>>>> Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty
>>>> exception specifications are discouraged by Boost guidelines - should appropriate checks be
>>>> added too?
>>>
>>> +1
>>
>> I don't think that Boost libraries are required to support non-conforming compilers or
>> operation modes of compilers, therefore adding inspect check for a workaround for such
>> non-comforming behaviour would be wrong, I think.
> 
> Why use BOOST_THROW_EXCEPTION to throw?
> 
> - Typically, there is no need to do anything else to support
> BOOST_NO_EXCEPTIONS builds;
> 
> - Enables boost::exception_ptr, so the exceptions you throw can be
> transported between threads;
> 
> - Enables boost::error_info, so users can attach stuff to exceptions.
> 
> - Enables better messages from boost::diagnostic_information.

I fail to see how the above refutes my statement. We don't have a requirement
that Boost libraries work with non-conforming environment. 
Nor is it required that any Boost library uses Boost.Exception.

Therefore, adding no-exceptions to inspect checks -- whose primary 
purpose is to beat authors whose libraries fail those checks -- would
be wrong.

-- 
Vladimir Prus
Mentor Graphics
[phone]