Subject: Re: [boost] program options (consider using BOOST_THROW_EXCEPTION)
From: Roger Martin (roger_at_[hidden])
Date: 2012-06-27 17:12:56
On 06/27/2012 04:51 PM, Emil Dotchevski wrote:
> On Wed, Jun 27, 2012 at 4:46 AM, Leo Goodstadt<leo.goodstadt_at_[hidden]>wrote:
>> However, the majority of exceptions in program_options are there to
>> indicate a problem in the construction of the command line by the
>> *end-user* (not the programmer).
>> In other words, the program *is* working exactly as designed.
> Unless it's buggy.
>> programmer has no interest in the provenance of these exceptions
>> *except* that they can be used to inform the end-user how they should
>> retype the command line and try again.
> The use case is this:
> int main( int argc, char const * argv )
> catch( X& )
> catch( Y& )
> std::cerr<< boost::current_exception_diagnostic_information();
> The catch(...) shouldn't be reached. The BOOST_THROW_EXCEPTION information
> could help if it is (of course the message is intended for the programmer,
> not the end user.)
Hi, when I first asked about this I wasn't comprehending the nature of
it being exceptions for the user but that makes complete sense. So from
your advice I'm planning to tee off the information to a DEBUG level
logger for the developer (untested):
catch( boost::program_options::unknown_option & e )
std::cout << "Command line incorrect: unknown option
std::cout << "\n" << desc << "\n";
This way a user sees the friendlier message yet if there is some
sleuthing to do, a developer or remote user may configure the runtime
log level and get the more detailed information that way
> Emil Dotchevski
> Reverge Studios, Inc.
> Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk