Consider renaming the API ThrowOnUnexpectedArgument

[parekhkb]

I am trying to make my app not throw an exception if the user enters an invalid command/option/argument.

I set ThrowOnUnexpectedArgument to false in the constructor of the CommandLineApplication. I also set a ValidationErrorHandler function.

However, an exception is still thrown.

[natemcmaster]

Can you provide repro steps? I have a guess, but it's hard to tell without knowing what is being passed in as args[] and what CommandBase.ConfigurationApplication is doing in your code.

[parekhkb]

Im calling dotnet MyApp.dll foo or dotnet MyApp.dll --foo both repro the issue.

Below are some relevant code snippets:

        private void ConfigureCommand(CommandLineApplication command, IServiceCollection services)
        {
            _services = services;

            command.Description = Description;
            command.HelpOption("-?|-h|--help");

            ConfigureCommandInternal(command);

            command.OnExecute(() => OnExecute(command));
        }

        protected override void ConfigureCommandInternal(CommandLineApplication command)
        {
            // Register sub-commands
            RegisterSubCommand<SubCommand1>(command);
            RegisterSubCommand<SubCommand2>(command);
            RegisterSubCommand<SubCommand3>(command);
            RegisterSubCommand<SubCommand4>(command);
        }

        public CommandLineApplication RegisterSubCommand<TCommand>(TCommand com, CommandLineApplication root) where TCommand : CommandBase
        {
            return root.Command(com.Name.ToLower(), c => com.ConfigureCommand(c, _services));
        }

        public CommandLineApplication RegisterSubCommand<TCommand>(CommandLineApplication root) where TCommand : CommandBase, new()
        {
            return RegisterSubCommand(new TCommand(), root);
        }

[natemcmaster]

Try changing this:

        public CommandLineApplication RegisterSubCommand<TCommand>(TCommand com, CommandLineApplication root) where TCommand : CommandBase
        {
-            return root.Command(com.Name.ToLower(), c => com.ConfigureCommand(c, _services));
+            return root.Command(com.Name.ToLower(), 
+              c => com.ConfigureCommand(c, _services),
+              throwOnUnexpectedArg: false);
        }

[parekhkb]

Thanks, @natemcmaster, that was indeed the issue. However I think there might be another bug: If I use throwOnUnexpectedArg: false. Then My OnValidationError Handler never get's called, and the app returns 0 rather than non-zero. I ended up just catching the ComandParsingException myself in order to write a useful message, eat the error, and return -1.

[natemcmaster]

What kind of validators have you configured? The app should return 1 by default if there are validation errors. ValidationErrorHandler is not invoked if there were not validation errors.

By the way, each subcommand is a new instance of CommandLineApplication, each with its own ValidationErrorHandler. Are you invoking a subcommand, but expecting the validation error handler on the root CommandLineApplication object to be called?

[parekhkb]

I see. Thanks for your help. I guess the issue I have with this feature is that it doesn't exit execution onValidationError.

[natemcmaster]

I think there is probably a bug here somewhere, I'm just not sure what it is. So far, I've identified at least two things that are not clear about the behavior of this API

• throwOnUnexpectedArgs has to applied to all subcommands explicitly. A better default may be to honor the value set on the root command instead of defaulting to false
• ValidationErrorHandler is only invoked on the command with the validation error, so you end up re-defining a customer error handler on all subcommand objects

Does this describe your issues so far? I'm not sure what you meant by the most recent comment about "it doesn't exit execution onValidationError."

[parekhkb]

Yes those two describe issues I've seen so far.

Here's what I mean by it doesn't exit execution onValidationError.

If I set throwOnUnexpectedArgs to false for the root and all sub-commands, and I specify an OnValidation() handler for each command, and my handler returns 3 (non-zero), then I would expect the app to exit after the onValidation handler is executed and the args are found to be invalid. Instead it proceeds to execute my app. For example. If I call dotnet MyApp.dll ValidCommand --valid-option --invalid-option, i would expect the existence of --invalid-option to prevent the app from doing what it would do if I just ran dotnet MyApp.dll ValidCommand --valid-option

To give you some context, this issue started when I tried to stop bad arguments from printing stack traces. I want bad arguments to fail the execution, but not print out exception stack traces.

[natemcmaster]

Oh, I see. Ok, so maybe this explanation will help.

What ThrowOnUnexpectedArgs:false means to the parser is "parse until you hit an unrecognized argument or option. Then, but everything else into the CommandLineApplication.RemainingArguments property".

For example:

Input	ValidOption.HasValue()	RemainingArguments (string[])
ValidCommand --valid-option --invalid-option	true	{ "--invalid-option" }
ValidCommand --invalid-option --valid-option	false	{ "--invalid-option", "--valid-option" }
ValidCommand banana --invalid-option --valid-option	false	{ "banana", "--invalid-option", "--valid-option" }

This behavior was added before this library every had support for validation on arguments. I realize now why this behavior isn't obvious. It's probably time to reconsider what the "throwOnUnexpectedArgs" value means.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please comment if you believe this should remain open, otherwise it will be closed in 7 days.

[natemcmaster]

Stale bot closed this, but I'd like to revisit this in 3.0. Reopening

[natemcmaster]

Finally got around to this. I've renaming the API. See #340 and #339. My plan is to obsolete the API in 2.6 and delete in 3.0. I'll be merging the changes soon to close this out, but it will probably take a few weeks to make any releases to nuget.org.