Problem-specifications: Exercises with non-standard error indicators

[Insti]

There are several exercises with non-standard error indicators.

The canonical data documentation says

If an error is expected (because the input is invalid, or any other reason), the value at "expected" should be an object containing exactly one property, "error", whose value is a string.

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: )
• [x] change (PR: #1340)
• [x] forth (PR: #1337)
• [x] grains (Issue: #1309 PR: #1322)
• [x] largest-series-product (Issue: #1310 PR: #1331)
• [x] ocr-numbers (PR: #1335)
• [x] pascals-triangle (PR: #1336)
• [x] phone-number (PR: #1337)
• [x] say (PR: #1337)
• [ ] trinary (PR: )
• [x] variable-length-quantity (PR: #1337)
• [x] wordy (PR: #1334)
• [x] queen-attack (PR: #1337)

See also: hamming canonical-data.json for another example of how to do things the right way.

[petertseng]

Anything in https://github.com/petertseng/exercism-problem-specifications that has to pass a custom error to verify must be using a non-standard error (Since the default error is the standard).

So, that'd be:

$ git grep 'error: ->' | cut -d/ -f2            (08-30 19:35)
binary
change
forth
grains
largest-series-product
ocr-numbers
pascals-triangle
say
trinary
variable-length-quantity
wordy

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)

[rpottsoh]

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?

[Insti]

@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.

[rpottsoh]

binary and trinary are deprecated, still should be considered?

[ErikSchierboom]

binary and trinary are deprecated, still should be considered?

I wouldn't mind them not having been updated to be honest. As they are deprecated, generators should be ignoring them I think.

[Insti]

Thanks for all your work on this @rpottsoh :heart:

[rpottsoh]

My pleasure, sorry again about #1337.

[rpottsoh]

Should trinary and binary be stricken from the list above since they are deprecated?

[ErikSchierboom]

Should trinary and binary be stricken from the list above since they are deprecated?

I would be fine with that.

Thanks for doing these @rpottsoh!

[rpottsoh]

If there are no more exercises to be added I think this issue can be closed.