[feature request]Reactions to undefined args

[LaplaceSoda]

When using an undefined argument (e.g. using -? after -h is defined to display help message), the program will directly report an error and exit. I wonder if it is possible to show the correct usage and help of the args before the program exits in that case.

[0382]

It is very hard to track all undefined arguments. Always use --help as the long name to pring help message. Then you can always get the right help message by program_name --help.

[LaplaceSoda]

Always use --help as the long name to pring help message. Then you can always get the right help message by program_name --help.

What I mean by this example is that the help message is hoped to be displayed before exiting when the program encounters an undefined argument.

[0382]

I make a small update, print the unparsed arguments when position argument number missmatching. Now it will show the unparsed -? if you define -h for help.

Because there are several kind of parse error in the library, I think it is not suitable to only print help message just in the specific condition. And you can always get the help message by run program_name --help, so print the help message may be unnecessary.

May be a better error display is needed for this library. I will compare some cmdline tools and try to improve the entire error display later.

[LaplaceSoda]

I make a small update, print the unparsed arguments when position argument number missmatching.

Thanks a lot!!!

Because there are several kind of parse error in the library, I think it is not suitable to only print help message just in the specific condition. And you can always get the help message by run program_name --help, so print the help message may be unnecessary.

May be a better error display is needed for this library. I will compare some cmdline tools and try to improve the entire error display later.

My idea is to assume that the user doesn't know the correct usage (even --help) when the wrong argument is entered. So the help message can be displayed before the error stops to remind the user of the correct usage.

[0382]

I compared some cmdling tools, and find that there is no common way to display errors, and no one can deal with every unexpected input clearly. So finally, I think your idea is a not bad solution. Now I add this%print_help() for every parse errors.

Now I use stop instead of error stop for parse errors, because these errors are shown for users. The build error and get error are the bug of the program, and should be fixed by developers, so they remain using error stop.

Tanks for your comments.

[LaplaceSoda]

Now I use stop instead of error stop for parse errors, because these errors are shown for users. The build error and get error are the bug of the program, and should be fixed by developers, so they remain using error stop.

Thank you very much, this seems much more reasonable.

But maybe the error message could be shown first, then the help message, and then stop, like this.

[0382]

Some times the help message may be very long, so I prefer print_help first.

[LaplaceSoda]

Some times the help message may be very long, so I prefer print_help first.

From a logical point of view, it is because there is an error that the help message is shown. So it should be the error message first, the help message last.

In addition, there is one more error will occur, the conversion error. This error occurs when one type (like integer) is required but other types (like a real number or string) is entered.

This type of error perhaps could be handled in the get method, for example

However, if we do so, the incorrectly entered value will replace the default value in the help message displayed and the get-function can't be pure, so other methods may also need to be adjusted.

[0382]

The error message is shown for users. So people should see it directly. If show error message first, when the help message is too long, then people must scroll up to find the error message. It is inconvenience.

I will add the type check later.

[LaplaceSoda]

OK，thank you very much!!!