Supplement clap::Error.info with helper methods #193
Comments
|
If we are breaking it, I would actually love the variants in |
|
After iterating with different error designs, I think our approach of a tag-only Kind with auxiliary data is the best approach (granted, how we expose that auxiliary data can be improved). The problem with enum fields is its brittle (can't add fields without breaking compat) and harder to check for just the kind ( The error working group is working on a general API for querying information from errors. Something like that seems like the best long-term solution. Short term, we can add our own query methods if we really need this before the Error WG gets their feature landed. |
|
Which feature is that?
In that case, shall I mark this as non 3.0 since it wont be breaking change? |
|
Dynamic member access, rust-lang/rfcs#2895 The RFC is old but it looks like work has restarted on this. Just today they were talking about this on their Zulip channel.
Agreed |
Tuesday Jul 27, 2021 at 00:09 GMT
Originally opened as clap-rs/clap#2628
Please complete the following tasks
Clap Version
3.0.0-beta.2
Describe your use case
Preface: thank you very much for your work on clap so far, it has saved me countless hours of tedium.
ErrorKindis a fieldless enum, so additional contextual information required for someone to provide their own custom error messages is provided as aVec<String>inError, namedinfo.Using a
Vecto carry this information not self-explanatory in regards to what each element of theVecrepresents (e.g. which element represents the invalid value that triggers anInvalidValueorValueValidation). This would be okay-ish if clap had any of the following:ErrororErrorKindto retrieve specific informationinfoto retrieve specific information based on where it should be in the vector.infowill be for a givenErrorKind.As far as I can tell, none of these are present, which means that in order to write one's own error reporting, one needs to either read the source code of the functions that construct these
Errors or do their own testing. I don't think either should be necessary.Describe the solution you'd like
The solution I'd prefer the most is a significant breaking change (described under Alternatives). I acknowledge that's not desirable, even considering the upcoming
3.0.0release.A compromise is to add ways to retrieve this information safely, such as by adding methods to
Errorthat return the relevant information. A few possible examples with placeholder names:pub fn get_arg_or_subcmd(&self) -> Option<&str>pub fn get_missing(&self) -> &[String]pub fn get_value_counts(&self) -> Option<(usize,usize)> //Found, expected.Implementing each method should be fairly simple, if perhaps a bit repetitive considering the number of variants on
ErrorKindthat need to be matched. The bodies would mostly be pattern matches followed by accesses toinfo.One caveat in the implementation is that
Errorshould contain a private flag to indicate whether theErrorwas constructed byError::with_descriptionor not. If so, these functions should return empty values.Alternatives, if applicable
This problem can technically be solved by improving documentation, but I'm of the mind that doing only that is the worst solution.
infobeing a Vec is fragile and typo-prone, and there should be better ways to interact with it than as aVec.Ideally, keeping
ErrorKindas a fieldless enum,info's type would change to an enum with fields that store the relevant information for each kind of error. Some of the methods described above could still be implemented for convenience.However, I acknowledge that this would be a significant breaking change that would take more than a few renames for users of clap to fix. Solutions like making
infoa method that generates aVec<String>from data in this enum or providing bothinfoand the enum in another field aren't entirely compelling either.Additional Context
I am very willing to work with you fine folks to implement any of these changes, if approved. Have a good day!
The text was updated successfully, but these errors were encountered: