Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parsing errors should include fields, not just text #26

Open
bpytlik opened this issue Nov 1, 2016 · 0 comments
Open

parsing errors should include fields, not just text #26

bpytlik opened this issue Nov 1, 2016 · 0 comments

Comments

@bpytlik
Copy link

bpytlik commented Nov 1, 2016

In the current code, if the user uses an option that doesn't exist, here's how the error gets thrown:

throw new Error(format('unknown option: "--%s"', name));

The main difficulty with this approach is that dashdash is making decisions about what the error string should be. If that string doesn't match the style of other error messages in the program using dashdash, then that program is left with either parsing the string of the error message and rebuilding it to match its style or living with two error styles.

I'll also mention that the current approach makes localization at least difficult (as you'd have to parse the error message again I think).

All that said, I think providing a default error message is very useful and I definitely wouldn't change that.

What I would change would be to have dashdash annotate the error messages it throws with additional information. In the example above, it would have a field, perhaps named name, which contained the value of the name parameter. Depending on the implementation choice, it would also either be a subclass of Error that's thrown (perhaps an UnknownOption error) or it would have a field indicating the error type that's thrown.

Ideally this would be done for each of the error types that dashdash can throw. The end goal is for programs that consume dashdash to be able to write their own error messages, using the information from dashdash to construct them appropriately.

If this sounds like something you're interested in, let me know and we can work our the details before I go implement a PR. If this isn't something you're interested in taking, I understand, I'll just use my own fork.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant