Re: [boost] program options (consider using BOOST_THROW_EXCEPTION)

Subject: Re: [boost] program options (consider using BOOST_THROW_EXCEPTION)
From: Rowan James (rowanj_at_[hidden])
Date: 2012-06-26 08:48:47

On 22 June 2012 17:51, Vladimir Prus <ghost_at_[hidden]> wrote:

> On 22.06.2012 11:33, Emil Dotchevski wrote:
>
>> On Thu, Jun 21, 2012 at 11:44 PM, Vladimir Prus<ghost_at_[hidden]>  wrote:
>>
>>  On 20.06.2012 07:44, Rowan James wrote:
>>>
>>>  On a related note; is there interest in a patch set to use
>>>> BOOST_THROW_EXCEPTION to add this (yes, programmer-oriented) information
>>>> to
>>>> the exceptions thrown by Program Options and/or other Boost libraries?
>>>>
>>>>
>>> Sorry, but I kinda miss context here (and I did read your original post).
>>> What are advantages of
>>> using BOOST_THROW_EXCEPTION and what are drawbacks? Could you summarize
>>> those for me?
>>>
>>>
>> Allow me :-
>>
>> BOOST_THROW_EXCEPTION, being a macro, is able to record the file name, the
>> function name, and the line number of the throw, which is useful when
>> diagnosing unexpected exceptions:
>>
>> catch(...)
>> {
>>   std::cerr<<  "Unexpected exception caught. Diagnostic information
>> follows.\n";
>>   std::cerr<<  boost::current_exception_**diagnostic_information();
>> }
>>
>> The exception object is examined dynamically for any and all useful
>> information: type, what(), throw location, any stored boost::error_info
>> objects, etc. The location of the throw (if available) is formatted in a
>> way Visual Studio understands: double-clicking shows the throw location,
>> similarly to double-clicking compile errors.
>>
>> The downside is that when templates are involved, BOOST_CURRENT_FUNCTION
>> (invoked by BOOST_THROW_EXCEPTION) can bloat the code. There is a Trac
>> ticket for this.
>>
>
> Emil,
>
> thanks for explaining. Given the above, I am not sure I am interested in
> using
> BOOST_THROW_EXCEPTION for program_options, given that exceptions are used
> there to report
> user mistakes mostly, and so function name or file line is of limited
> interest.
>
> Thanks,
> Volodya

Thanks Emil.

If I can make the case in favour of BOOST_THROW_EXCEPTION, it is for the
very reason that they are reporting user mistakes.  The throw location for
an exception is typically accompanied by, or at least close to, the logic
that delineates such a user mistake from acceptable input.  As such, it is
a useful remedy in itself; but also gives the user specific information for
finding documentation relevant to fixing the error.  Without it, we have at
best the entry point into the library that; and often a lot less if the
exceptions are caught at a higher level.

Documentation for valid inputs or states to a function can only say so much
about all the possible errors or exceptions that may occur.