headers
Roger Martin | 19 Jun 2012 15:12

program options (consider using BOOST_THROW_EXCEPTION)

Hi boost,

At version 1.49.0

In testing command line with known unknowns such as -V a location 
unknown exception is thrown from inside program_options recommending to 
use BOOST_THROW_EXCEPTION.  I've been trying to find this and apply 
BOOST_THROW_EXCEPTION to eliminate the verbosity for users:
----
Command line incorrect: Throw location unknown (consider using 
BOOST_THROW_EXCEPTION)
Dynamic exception type:

boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::unknown_option> 
 >
std::exception::what: unknown option -V
----

With this fixed then it'd be closer to:
--------
Command line incorrect: unknown option -V
--------

Yet I haven't found where.  Baffled. Any hint?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Emil Dotchevski | 19 Jun 2012 21:55
Picon

Re: program options (consider using BOOST_THROW_EXCEPTION)

On Tue, Jun 19, 2012 at 6:12 AM, Roger Martin <roger <at> quantumbioinc.com>wrote:

> Hi boost,
>
> At version 1.49.0
>
> In testing command line with known unknowns such as -V a location unknown
> exception is thrown from inside program_options recommending to use
> BOOST_THROW_EXCEPTION.  I've been trying to find this and apply
> BOOST_THROW_EXCEPTION to eliminate the verbosity for users:
> ----
> Command line incorrect: Throw location unknown (consider using
> BOOST_THROW_EXCEPTION)
> Dynamic exception type: boost::exception_detail::**
> clone_impl<boost::exception_**detail::error_info_injector<**
> boost::program_options::**unknown_option> >
> std::exception::what: unknown option -V
>

The output you're seeing is generated  by boost::diagnostic_information,
and that's not a user-friendly but rather a diagnostic message. The
suggestion to use BOOST_THROW_EXCEPTION refers to the "Throw location
unknown". If BOOST_THROW_EXCEPTION was used by the library, the diagnostic
message would have been more complete and include the file/line of the
throw.

Just catch boost::program_options::unknown_option and display a
user-friendly message:

catch( boost::program_options::unknown_option & e )
(Continue reading)

Permalink | Reply |
headers
Rowan James | 20 Jun 2012 05:44

Re: program options (consider using BOOST_THROW_EXCEPTION)

On 20 June 2012 05:55, Emil Dotchevski <emildotchevski <at> gmail.com> wrote:

> On Tue, Jun 19, 2012 at 6:12 AM, Roger Martin <roger <at> quantumbioinc.com
> >wrote:
>
> > Command line incorrect: Throw location unknown (consider using
> > BOOST_THROW_EXCEPTION)
> > Dynamic exception type: boost::exception_detail::**
> > clone_impl<boost::exception_**detail::error_info_injector<**
> > boost::program_options::**unknown_option> >
> > std::exception::what: unknown option -V
> >
>
> The output you're seeing is generated  by boost::diagnostic_information,
> and that's not a user-friendly but rather a diagnostic message. The
> suggestion to use BOOST_THROW_EXCEPTION refers to the "Throw location
> unknown". If BOOST_THROW_EXCEPTION was used by the library, the diagnostic
> message would have been more complete and include the file/line of the
> throw.
>
>
Or, to use the plain information in the exception; ignore the diagnostic
information and just use the what() member of the exception:

try
{
    // ...
}
catch (std::exception& ex)
{
(Continue reading)

Permalink | Reply |
headers
Vladimir Prus | 22 Jun 2012 08:44
Picon
Favicon

Re: program options (consider using BOOST_THROW_EXCEPTION)

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?

Thanks,
Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Emil Dotchevski | 22 Jun 2012 09:33
Picon

Re: program options (consider using BOOST_THROW_EXCEPTION)

On Thu, Jun 21, 2012 at 11:44 PM, Vladimir Prus <ghost <at> 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
(Continue reading)

Permalink | Reply |
headers
Vladimir Prus | 22 Jun 2012 09:51
Picon
Favicon

Re: program options (consider using BOOST_THROW_EXCEPTION)

On 22.06.2012 11:33, Emil Dotchevski wrote:
> On Thu, Jun 21, 2012 at 11:44 PM, Vladimir Prus<ghost <at> 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();
> }
>
(Continue reading)

Permalink | Reply |
headers
Rowan James | 26 Jun 2012 14:48

Re: program options (consider using BOOST_THROW_EXCEPTION)

On 22 June 2012 17:51, Vladimir Prus <ghost <at> 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 <at> 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";
(Continue reading)

Permalink | Reply |
headers
Alex Perry | 26 Jun 2012 19:03

Re: program options (consider using BOOST_THROW_EXCEPTION)


 Rowan James on 26 June 2012 13:49 wrote :
>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.

+1 here

I had a case of this with either program_options or property_tree (can't remember which) not that long ago
and remember wishing that the library had used boost exceptions rather than some boost:any derived
library specific error handling for this very reason. Instead had to step through library code to work out
why it had a problem with the particular input.

Alex Perry

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Sebastian Redl | 26 Jun 2012 20:01
Picon
Favicon

Re: program options (consider using BOOST_THROW_EXCEPTION)


On 26.06.2012, at 19:03, Alex Perry wrote:

> 
> 
> Rowan James on 26 June 2012 13:49 wrote :
>> 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.
> 
> +1 here
> 
> I had a case of this with either program_options or property_tree (can't remember which) not that long ago
and remember wishing that the library had used boost exceptions rather than some boost:any derived
library specific error handling for this very reason. Instead had to step through library code to work out
why it had a problem with the particular input.

That would be PropertyTree, and I'll put changing that on my todo list. (I do use Boost.Exception, I think,
but I'm not attaching information.)

Sebastian

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Alex Perry | 27 Jun 2012 12:59

Re: program options (consider using BOOST_THROW_EXCEPTION)


 Sebastian Redl on 26 June 2012 19:02 wrote :

> That would be PropertyTree, and I'll put changing that on my todo list. (I do use Boost.Exception, I think,
but I'm not attaching information.)
>
> Sebastian

That would be great thanks! - though my comment was not meant to criticize  propertyTree in particular - it's
a very useful library - was more trying to use an example to add weight to a general wish that exceptions for 
boost libraries were more consistent (and including information only available at throw site when
applicable) - since this just makes using them even easier given the number of boost libraries that exist now.

Alex

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Vladimir Prus | 27 Jun 2012 11:41
Picon
Favicon

Re: program options (consider using BOOST_THROW_EXCEPTION)

On 26.06.2012 21:03, Alex Perry wrote:
>
>
> Rowan James on 26 June 2012 13:49 wrote :
>> 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.
>
> +1 here
>
> I had a case of this with either program_options or property_tree (can't remember which) not that long ago
and remember wishing that the
> library had used boost exceptions rather than some boost:any derived library specific error handling
for this very reason. Instead had to
> step through library code to work out why it had a problem with the particular input.

What practical value would source location somewhere in any.hpp give you?

- Volodya
(Continue reading)

Permalink | Reply |
headers
Alex Perry | 27 Jun 2012 14:14

Re: program options (consider using BOOST_THROW_EXCEPTION)


Vladimir Prus on 27 June 2012 10:41 wrote :

> What practical value would source location somewhere in any.hpp give you?
>
>- Volodya

Minor value I admit - but as I think someone mentioned earlier - its very easy to move to this throw site after
catching the exception in application code and then can add a breakpoint  and rerun.

Then can explore the problem in the "correct context" of the code - stepping through all the library code
whilst obviously possible can just take a long time - particularly as the code organisation in the library
(for sensible reasons) will be more complex than I really want to know about as a user - being able to start at
the correct "implementatioin/detail" level with (hopefully) the code which was complaining about the
input nearby does help.

Alex

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Rowan James | 27 Jun 2012 14:38

Re: program options (consider using BOOST_THROW_EXCEPTION)

On 27 June 2012 22:14, Alex Perry <Alex.Perry <at> smartlogic.com> wrote:

>
> Vladimir Prus on 27 June 2012 10:41 wrote :
>
> > What practical value would source location somewhere in any.hpp give you?
> >
> >- Volodya
>

> Minor value I admit - but as I think someone mentioned earlier - its very
> easy to move to this throw site after catching the exception in application
> code and then can add a breakpoint  and rerun.
>
> Alex

Indeed, at the very least it's a source location to put a breakpoint at.
 It doesn't pollute the output of what() where meaningful messages have
been put in, but does supplement diagostic_information(...), which I at
least only output to internally-visible or debug streams; not user-visible
messages.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Leo Goodstadt | 27 Jun 2012 13:46
Picon

Re: program options (consider using BOOST_THROW_EXCEPTION)

> On 22 June 2012 17:51, Vladimir Prus <ghost <at> 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 <at> 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";
(Continue reading)

Permalink | Reply |
headers
Alex Perry | 27 Jun 2012 14:34

Re: program options (consider using BOOST_THROW_EXCEPTION)



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
(Continue reading)

Permalink | Reply |
headers
Rowan James | 27 Jun 2012 14:36

Re: program options (consider using BOOST_THROW_EXCEPTION)

On 27 June 2012 21:46, Leo Goodstadt <leo.goodstadt <at> llew.org.uk> wrote:

>
> To elaborate on what Volodya said, program_options is unusual (for
> Boost) library in its use of exceptions:
>
> Most of the time, exceptions are there to inform the programmer of an
> error in the programme.
>
> 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. 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.

>

It is entirely unhelpful for the end-user to have
> Exception XXX on line xxx of file yyy....
>

I don't understand BOOST_THROW_EXCEPTION( ) to replace the output of
.what() - but to supplement the output of boost::diagnostic_information( ),
which I'm advocating for when the program is being tested by the
development team.  The diagnostics in my situation wouldn't be end-user
visible.

To make it easier to use program options *in English*, the exception
(Continue reading)

Permalink | Reply |
headers
Emil Dotchevski | 27 Jun 2012 22:51
Picon

Re: program options (consider using BOOST_THROW_EXCEPTION)

On Wed, Jun 27, 2012 at 4:46 AM, Leo Goodstadt <leo.goodstadt <at> 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(...)
(Continue reading)

Permalink | Reply |
headers
Roger Martin | 27 Jun 2012 23:12

Re: program options (consider using BOOST_THROW_EXCEPTION)

On 06/27/2012 04:51 PM, Emil Dotchevski wrote:
> On Wed, Jun 27, 2012 at 4:46 AM, Leo Goodstadt<leo.goodstadt <at> 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(...)
(Continue reading)

Permalink | Reply |

Gmane