Re: GET_LONG_ANSWER error return
- Posted by slowmaker Jun 03, 2013
- 1507 views
The documentation seems to me to be saying that the value("John", ,GET_LONG_ANSWER) call should return a 1 in the third element, as that is the point at which the error was detected, i.e. the very first character.
The documentation and the library are correct. The documentation is a bit ambiguous though. The key point is that the third item is the count of characters read so far in the processing. So therefore, if the first character is invalid, then the number processed so far is zero.
Your test case should read ...
test_equal("value() bad integer [LONG ANSWER]", {GET_FAIL, 0, 0, 0}, value("John",,GET_LONG_ANSWER))
We need to put in a LOT more test cases for this function.
Okay, so restating to check my understanding: where the docs for these two routines say 'read', I should be thinking 'read and validated as part of a legitimate Euphoria object', correct?
Regarding ambiguity: yes definitely. After all, it does read one character. Even the word 'processed' does not necessarily imply successful interpretation/translation; if a character has been read and deemed 'bad' for the current context, you could make a good case for the viewpoint that it has been processed.
Likewise with the other phrase:
On an error, this is the point at which the error was detected." (emphasis added)
To me, that phrasing would have meant I could use that number as an index to put me smack dab on the first bad/illegal/nonconforming character. As you have pointed out, that is not the case after all.
The only problem is, having said all this and claimed ambiguity for the existing phrasing, I don't really have any better phrasing to suggest; crap. The phrase I used above, 'read and validated as part of a legitimate Euphoria object', works for me, but it's extremely verbose and probably has its own vagueness I'm just not seeing because I thought of it.
Anyway, skipping the vague docs phrasing, thanks for the clarification. I'm definitely going to need to start over on my rewrite of get() & company; the approach I initially took, apart from other issues it has, is almost entirely based on the assumption that the docs meant the way I initially assumed (i.e. opposite what has been now stated as the right way).
Back to building test cases...
