© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
I looked at this a bit and it's not clear that adding the end line/column really adds any useful information for the user. For the possible exceptions that can be thrown, most of the time the end line/column would be exactly the same as the start line/column -- either that, or it's difficult to compute what the correct end line/column should be.
* illegal_character: end line/column would always be the same as start line/column.
* illegal_codepoint: the current start line/column points to the character position in the JSON at which the illegal character comprising the codepoint is. For example, given "\uEFG0", the code currently set the start line/column to point at the 'G' since that's the character that's illegal. If you wanted to have a distinct end line/column, then you *could* make start line/column point to the \ (the start of the code-point) and end line/column point to the '0' (the end of the code-point), but, to me, that's actually *less* useful since it doesn't say which character is the illegal one.
* illegal_literal: here, you could actually make a case for having start line/column point to the first character of the literal and end line/column point to the last character of the literal. However, for a literal like:
false_
the code would actually have to continue to scan to the end of the literal to find its end rather than fail immediately upon encountering the '_' which is what happens now. Is that really worth it when start line/column point to the 'f' in "false" now?
* illegal_number: same argument as illegal_literal.
* unterminated_
* illegal_escape: end line/column would always be start line/column+1.
* unexpected_token: the end line/column could be the position of the last character of the token, but this really is not useful information if you have the start line/column.
Hence, I really don't think it's worth doing.