-
-
Notifications
You must be signed in to change notification settings - Fork 546
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
Exercises with non-standard error indicators #1311
Comments
Anything in https://github.com/petertseng/exercism-problem-specifications that has to pass a custom So, that'd be:
Note that that is a sufficient condition but not a necessary condition, so the omission of any exercise in this list does not give it a free pass (particularly, please still do pay attention to phone-number and queen-attack even though they are not in my list but are in the list in the issue description) |
Is #902 worth considering again? Do all these exercises need to be testing for invalid input? Is looking for invalid input germane to the exercise, if not can those cases be removed from their respective exercises? |
@petertseng nice, you've picked up some I didn't find (probably because the Ruby track doesn't have generators for them.) @rpottsoh probably. I'm strongly in favor of removing invalid input related tests. |
binary and trinary are deprecated, still should be considered? |
per exercism#1311 proper error handling object incorporated into last two test cases.
I wouldn't mind them not having been updated to be honest. As they are deprecated, generators should be ignoring them I think. |
change 1.3.0 As proposed in #1313 #905 (comment) In contrast to the proposal in #336 (comment) Although -1 is a sentinel value, the sentinel value had been overloaded in this JSON file to mean two separate conditions: * "Can't make target" (ostensibly, we might be able to make the target with a different set of coins) * "Target is negative" (no matter what coins we provide, this target is always invalid) To make clear that these two conditions are different, we use an error object describing each. This error object was defined in #401 Note that this commit is not a decree that all languages must represent these conditions as errors; languages should continue to represent the conditions in the usual way for that language. It is simply a declaration that these two conditions bear enough consideration that we'll represent them with a different type and also clearly differentiate between the two. Closes #1313 Checks the related box in #1311
binary-search 1.2.0 As discussed in #1312 Although -1 is a sentinel value, using this sentinel value is not the usual course of action in some languages. In using an error object, we avoid giving the wrong idea that we are requiring the use of the sentinel value. This error value was defined in #401 Of course, languages that wish to use a sentinel value may continue to do so; this commit is not intended to decree that sentinel values are forbidden. Neither is this commit decreeing that all languages must represent this condition as an error; it is simply a declaration that this condition bears enough consideration that we'll represent it with a different type. Closes #1312 Checks the related box in #1311
per exercism#1311 pascals-triangle: update comment re: errors Per @Insti's suggestion....
per exercism#1311 proper error handling object incorporated into last two test cases. wordy: lowerCased error message 2nd word per @ErikSchierboom suggestion. wordy: reworded comment to indicate 'error' per @Insti's request. wordy: error messages more helpful.
per exercism#1311 ocr-numbers: remove redundant comment per @Insti's suggestion. ocr-numbers: add clarity to error messages per @Insti suggestion. ocr-numbers: improved wording of error messages
Thanks for all your work on this @rpottsoh ❤️ |
My pleasure, sorry again about #1337. |
Should |
I would be fine with that. Thanks for doing these @rpottsoh! |
If there are no more exercises to be added I think this issue can be closed. |
There are several exercises with non-standard error indicators.
The canonical data documentation says
I started creating issues for these but found there were a few more, so I've grouped them all together here.
Todo:
Update the
canonical-data.json
for each exercise to use the correct error format.Exercises:
binary (PR: )trinary (PR: )See also: hamming canonical-data.json for another example of how to do things the right way.
The text was updated successfully, but these errors were encountered: