Option with nullable type causes InvalidOperationException when parsing invalid value

Problem

If I use a nullable type for an Option<T> (which is useful for determining whether the option was specified at all), and an invalid value is provided to that Option on the command line, the application will crash with an InvalidOperationException. It does not crash if the Option type is not nullable.

I will freely admit that using a nullable type for an Option may not be the "correct" approach; it seemed like the most expedient way to identify whether an option was specified by the user.

Example for Reproducing

For example, invoking the following application with arguments "--test ouch" will crash:

using System.CommandLine;
using System.CommandLine.Builder;
using System.CommandLine.Parsing;

RootCommand rootCommand = new("example-app");
Option<bool?> testOption = new("--test");
rootCommand.AddOption(testOption);
rootCommand.SetHandler(rootHandler, testOption);
CommandLineBuilder builder = new(rootCommand);
return builder.Command.InvokeAsync(args).Result;

async Task<int> rootHandler(bool? test)
{
	Console.WriteLine("In handler");
	return 0;
}

Unhandled exception: System.InvalidOperationException: Cannot parse argument 'ouch' for option '--test' as expected type 'System.Boolean'.
   at System.CommandLine.Binding.ArgumentConverter.GetValueOrDefault[T](ArgumentConversionResult result)
   at System.CommandLine.Parsing.SymbolResult.GetValueForOption[T](Option`1 option)
...

But if I change it to Option<bool> instead of Option<bool?> (and the corresponding change to rootHandler), then there's no crash:

'ouch' was not matched. Did you mean one of the following?
-h
Unrecognized command or argument 'ouch'.

Description:
  example-app
...

Proposed Solutions

1. Support nullable types for Option so they are handled more like "regular" types from an end user standpoint.
2. Block the use of nullable types for Option (provided there is a different/better way to determine whether an option was specified).

[jonsequitur]

The SetHandler overloads supporting parameter binding have been removed so I don't think this bug is present in the latest code.

Thanks! It took a little while to figure out how the new version (2.0.0-beta4.23306.1) works, so I might be doing it all wrong, but it's still throwing an unhandled exception in ParseResult.GetValue with a nullable Option type and passing in --test ouch:

using System.CommandLine;

CliRootCommand rootCommand = new("example-app");
CliOption<bool?> testOption = new("--test");
rootCommand.Options.Add(testOption);
rootCommand.SetAction((parseResult) => rootHandler(parseResult));
rootCommand.Parse(args).Invoke();

int rootHandler(ParseResult result)
{
	bool? test = result.GetValue(testOption);
	Console.WriteLine($"test: {test}");
	return 0;
}

If I change it from CliOption<bool?> to CliOption<bool>, then it works correctly.

[jonsequitur]

Thanks for the repro!

Thank you for fixing this - it's much appreciated!