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
>>>> 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:
>> std::cerr<< "Unexpected exception caught. Diagnostic information
>> 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.
> thanks for explaining. Given the above, I am not sure I am interested in
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk