Subject: Re: [boost] program options (consider using BOOST_THROW_EXCEPTION)
From: Alex Perry (Alex.Perry_at_[hidden])
Date: 2012-06-27 08:34:32
Leo Goodstadt on 27 June 2012 12:46 wrote :
> It is entirely unhelpful for the end-user to have Exception XXX on line xxx of file yyy....
Agree totally - but this is up to the application to decide what to present to the user - the point is that this information can be very useful to the developer of the application and with appropriate log files / application state dumps makes handling user reported errors much easier to recreate and fix.
>To make it easier to use program options *in English*, the exception messages have been recently rewritten to be maximally informative to the end-user rather than the >programmers. Thus we can take e.what() and write it out to std::cerr without further ado.
>Of course, for localisation, these error messages have to be reconstructed in the appropriate language. Hopefully, there is enough data in each exception to allow this.
Whilst sensible error information is always a plus I'm not sure that you as a library writer are in any position to determine what is "maximally informative to the end-user" - thatâs my job when writing the application when I've got some idea about the prospective user community.
>Curiously, the current design of exceptions in program_options ended up try to mirror what Emil has done in BOOST_THROW_EXCEPTION. When the exception is thrown deep in the >bowels of the command line parsing, it does not have the full context which would allow an informative message to be constructed.
>The exception has to be propagated up, and then "decorated" before being rethrown.
More than curious I'd say - I imagine that you explored just using it first - were there substantive reasons not to use it? Are there possible enhancements to boost.exception which could make it useable by your library in the future?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk