You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
In the current code, if the user uses an option that doesn't exist, here's how the error gets thrown:
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 thename
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.
The text was updated successfully, but these errors were encountered: