flag: clean up error message

[vrothberg]

What version of Go are you using (go version)?

go version go1.9.7 linux/amd64 (but it affects basically all versions of go).

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

GOHOSTARCH="amd64"
GOHOSTOS="linux"

What did you do?

Provide a non-numerical input for an integer flag yields the following error:

invalid value "donut" for flag -cpu-quota: strconv.ParseInt: parsing "donut": invalid syntax

What did you expect to see?

--cpuquota is expecting an integer

Something more user-friendly. Currently, the error message must be interpreted by the user and should guide users a bit more in a direction to solve the issue. See containers/buildah#673 as an example.

What did you see instead?

invalid value "donut" for flag -cpu-quota: strconv.ParseInt: parsing "donut": invalid syntax

Proposal

I want to suggest two options:

1. Update the error messages (e.g., for integer flags https://golang.org/src/flag/flag.go?s=8120:8324#L912).
2. Expose public error types (e.g., ErrInvalidValue and ErrInvalidBoolen) that can be used by users of the flag package (e.g., urfave/cli).

[robpike]

The error message can be improved, but changing the public API requires going through the proposal process. Updating the issue.

[vrothberg]

Thanks a lot, @robpike, for the quick response. Much appreciated!

Improving the error messages sounds good to me.

[rsc]

What's missing from this proposal is the proposal of what the new API looks like.

The current five errors are:

return false, f.failf("bad flag syntax: %s", s)
return false, f.failf("invalid boolean value %q for -%s: %v", value, name, err)
return false, f.failf("invalid boolean flag %s: %v", name, err)
return false, f.failf("flag needs an argument: -%s", name)
return false, f.failf("invalid value %q for flag -%s: %v", value, name, err)

As far as exported API, can we make do with a single new flag.Error struct, or do these need to be multiple error types? Maybe something like:

type Error struct {
    Flag *Flag
    Value string
    Implicit bool
    Err error 
}

is at least a starting point for a discussion.

[vrothberg]

@rsc, thanks a lot for looking into the issue.

As far as exported API, can we make do with a single new flag.Error struct, or do these need to be multiple error types?

[updated]:
There are actually cases where it's really helpful to distinguish the errors (e.g.,
urfave/cli#758 (comment)). Having different types of errors would avoid string compares.

It may be the lack of coffee, but the meaning of the Implicit bool field is not obvious to me. @rsc, could you explain your intention behind that field?

[ianlancetaylor]

I'm not sure what Implicit is for but don't worry about it. Construct a type that lets you recreate the existing errors and let's see how it looks. Thanks.

[rsc]

Implicit was to distinguish between -x=true and -x for a boolean x. (is "Value" implicit?)

Does anyone want to sketch an implementation and based on that send back a proposed API?