Intended way to check ErrorKind with value_t!

[dimo414]

The value_of_t functions added in #1811 say to "Check ErrorKind to distinguish" between parse failures and absent values. The same expectation is implied in the existing value_t! macros. But it's not clear to me how you're supposed to actually do that; what I've got so far feels very verbose and tedious:

// Approach 1, match-ing the Result
let arg: Option<Duration> = match value_t!(matches.value_of("arg"), humantime::Duration) {
    Ok(t) => Ok(Some(t.into())),
    Err(e) => {
        match e.kind {
            ::clap::ErrorKind::ArgumentNotFound => Ok(None),
            _ => Err(e),
        }
    }
}.unwrap_or_else(|e| e.exit());

// Approach 2, using map_or_else
let arg: Option<Duration> = value_t!(matches.value_of("arg"), humantime::Duration)
    .map_or_else(|e| match e.kind {
            ::clap::ErrorKind::ArgumentNotFound => Ok(None),
            _ => Err(e),
        },
        |v| Ok(Some(v.into())))
    .unwrap_or_else(|e| e.exit());

Both of these feel cruftier than just re-implementing value_t! manually and handling the absent case directly, but that too is verbose:

// Approach 3: don't use value_t! at all...
let arg: Option<Duration> = matches.value_of("arg")
    .map(|v|
        v.parse::<humantime::Duration>()
            .map_err(|v| ::clap::Error::value_validation_auto(format!("The argument '{}' isn't a valid value", v)))
            .unwrap_or_else(|e| e.exit())
            .into());

Is there a different syntax that expresses this more clearly? What is the intended way for value_t!/value_of_t() users to handle ArgumentNotFound?

@CreepySkeleton tagging you since you implemented value_of_t().

[pksunkara]

Well, you should probably handle parse failures before even coming here, so you generally don't need to check error kinds.

[dimo414]

I'm not sure what you mean; parsing the command line has already happened at this point, but parsing individual arguments into different types can still hit ArgumentNotFound, as the documentation says.

[pksunkara]

Hmm.. Can you provide me a minimal example and the inputs you are trying and outputs you are expect?

[dimo414]

You can see that the value_t! macro and the value_of_t() function treat absence as an error, which is different from value_of().

In the examples above, if a user passes --arg=foo it should fail, because foo is not a valid Duration string. But if they don't pass --arg at all that is treated as an ArgumentNotFound error. The fact that parse failures (user error) and unspecified options (expected) both lead to errors seems to mean the developer has to jump through hoops to actually distinguish these two cases. The documentation suggests doing so by checking the ErrorKind, but I am struggling to find a clean way to do so. The cleanest approach I've identified is to just not use the macro/function at all (my third approach above), which seems wrong, so I'm asking if there's an intended pattern for using value_t!/value_of_t().

[pksunkara]

The fact that parse failures (user error) and unspecified options (expected) both lead to errors seems to mean the developer has to jump through hoops to actually distinguish these two cases

This seems intentional to me. It provides more flexibility to the developers.

If you actually care about the value existing in the first place, you would build the Arg such that it always takes a value which would let clap handle that error and then you would not encounter this case.

[dimo414]

The intent is to support optional arguments, not require that it be set. This is well supported for strings but the value_t! macro makes this cumbersome.

It provides more flexibility to the developers.

Can you elaborate on how developers are supposed to take advantage of this flexibility? That's the crux of my question. I am trying to use value_t! with an optional argument and my attempts have been verbose and unwieldy. Is one of my approaches above the intended way to work with value_t!? If not, what's the expected pattern?

[pksunkara]

Sorry, took me a bit of time to understand what you are asking for. All the approaches you wrote are idiomatic. But I agree, things can be improved to handle the optional cases better. Can you please create an issue for this?

[dimo414]

Thanks! I just filed #2505 and would be happy to contribute a PR to improve this.