On 22 June 2012 17:51, Vladimir Prus <ghost@cs.msu.su> wrote:
On 22.06.2012 11:33, Emil Dotchevski wrote:
On Thu, Jun 21, 2012 at 11:44 PM, Vladimir Prus<ghost@cs.msu.su> 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.