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?
Alex