On 06/27/2012 04:51 PM, Emil Dotchevski wrote:
On Wed, Jun 27, 2012 at 4:46 AM, Leo Goodstadt<leo.goodstadt@llew.org.uk>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.
The
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[] ) { try { do_work(parse_command_line(argc,argv)); } catch( X& ) { } catch( Y& ) { } catch(...) { std::cerr<< boost::current_exception_diagnostic_information(); abort(); } }
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 "<<e.get_option_name(); std::cout.flush(); std::cout << "\n" << desc << "\n"; LOG4CPLUS_DEBUG(logger, boost::diagnostic_information(e)); }
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. http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost