Confusing error message when missing "required" options

[fgabolde]

When a script specifies "required" options:

describe_options('perl mwe.pl %o', [ 'foo=s', 'the foo', { required => 1 } ]);

and the user forgets to include them, we get a confusing error message:

Mandatory parameter 'foo' missing in call to "eval"

Now I know what's meant because I'm used to GLD's idiosyncrasies but it's not very user-friendly...

Looking at the source, I can see it's because Params::Validate is assuming it's being called as validate() within a function, so it can include its name in the error message (and GLD is in fact calling validate_with() in an eval). I checked, and there seems to be no way to tell Params::Validate not to include the caller name (although there is a way to tell it to skip some frames from the stack... but of course the "correct" caller would just be "(unknown)" in that case, so that's not much better). There remains the possibility to munge the error message within the custom on_fail handler in GLD.

Does that sound like a PR you'd want?

[rjbs]

At the very least, I would like a PR that gets rid of the "in call to eval" and says something like "--foo is required but was not given" yes. :)

[fgabolde]

@rjbs I can't figure out how to do it in a non-brittle fashion -- if the error messages from PV change, any munging is going to break. I'll try to make it so it just passes through the PV error if it is not recognizable.

I can see another weird error message, in the case of one_of:

The 'bar' parameter ("1") to "eval" did not pass the 'bar implies mode=bar' callback: option specification for bar implies that mode should be set to 'bar', but it is 'foo' already

Should I include a fix for this, too?

[tsibley]

@fgabolde Did you ever start in on a patch for this? I'd love to see a better error message.

[tsibley]

If you haven't started, I might!

[fgabolde]

@tsibley I think I have the start of a patch on my work machine yes, but nothing very finished. I don't have access to it right now but I don't remember having gone far with it -- if you're still interested in this patch you're probably better off not waiting for me to finish :/ although I can send you what I've done if I can find it on Monday.

[tsibley]

Params::Validate allows for changing the calculated "eval" to an arbitrary string by passing the called parameter to validate_with(). Getopt::Long::Descriptive might do called => prog_name(), but that still leaves error messages that at the least aren't straightforward and at the most are downright confusing.

The best option would be if Params::Validate had exception objects that Getopt::Long::Descriptive could catch and use to build its own error messages. That sounds like a lot of work though and involves patches to other modules.

Another option then is parsing the messages to figure out what went wrong and trying to reassemble better ones.

Obviously we can't parse everything perfectly (and it will be somewhat brittle if Params::Validate changes), but we can try to parse common errors that might happen. Two that come to mind from my experience are:

• A missing required normal option: Mandatory parameter 'foo' missing in call to "eval" → --foo is required but was not given.
• A missing required one_of option¹: Mandatory parameter 'mode' missing in call to "eval" → One of --foo, --bar, or --baz is required but none were given.

Scrolling through Params::Validate::PP looking at calls to on_fail, there are more that might be nice to handle too (number of values, type of value, etc).

¹ Example:

    [ "mode", [
        [ "foo", "do foo" ],
        [ "bar", "do bar" ],
        [ "baz", "do baz" ]],
        { required => 1 },
    ],

[tsibley]

@fgabolde Ok, thanks! I'd be curious to see what headway you made, but if you can't dig it up no worries.

[fgabolde]

@tsibley Sorry, it disappeared along with my old hard drive, I think.

[van-de-bugger]

Hi,

Is there any progress on that? Ugly Mandatory parameter 'foo' missing in call to "eval" is still here in 2024.

[rjbs]

Not that I'm aware of.