-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Allow reporting locations of semantic errors #57
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
Comments
Are you using this? I want to decouple the Value from the start/limit info used only during parsing, for both clarity and memory efficiency. For now, I want to delete |
I am currently using this functionality, but I don't see why we couldn't decouple the start/limit info if we stored the row/column information in the We define a
Example usage:
Benefits:
Areas for improvement:
|
I don't oppose semantic parsing in principle, but I wonder whether you wouldn't be better off with XML. JSON has no semantic information; it's just a data-interchange format. Even in your example the entire JSON document is read before Why can't you wrap a This odd method stands in the way of a more efficient JSON parser. How strongly would you object to its removal in v1.4.0? Or at least in v2.0.0? |
I wouldn't object to it's removal, but it would be nice if there were methods to facilitate semantic assertions. The "right" way would probably be to define semantic constraints before parsing. It might even be possible to implement parse-time no-copy initialization of STL and user defined classes. That being said, c++ is a systems programming language. Whatever needs to be done to improve efficiency is fine by me. |
Nevermind. It's a harmless addition to the current Reader. Someday, we might have a new Reader without any error-reporting, but it's fine for now. |
What would you think of a
Example usage: Reading in vectors of doubles
|
for binary-compatibility with 0.6.0 issue open-source-parsers#147 was open-source-parsers#57
for binary-compatibility with 0.6.0 issue open-source-parsers#147 was open-source-parsers#57
for binary-compatibility with 0.6.0 issue open-source-parsers#147 was open-source-parsers#57
for binary-compatibility with 0.6.0 issue open-source-parsers#147 was open-source-parsers#57
for binary-compatibility with 0.6.0 issue open-source-parsers#147 was open-source-parsers#57
for binary-compatibility with 0.6.0 issue open-source-parsers#147 was open-source-parsers#57
for binary-compatibility with 0.6.0 issue open-source-parsers#147 was open-source-parsers#57
It would be nice if there were a mechanism for reporting the locations of semantic errors (e.g. incorrect value type). It looks like the functionality is almost there with
Value::getOffsetStart()
. Perhaps something like:which would use the Value offset and
Reader::begin_
to calculate aReader::Location
and push_back aReader::ErrorInfo
ontoReader::errors_
. The error could then be printed with a call toReader::getFormattedErrorMessages()
. Perhaps there could be a:that also initializes
Reader::ErrorInfo::extra_
.Of course then it would be nice to have a function
to return
!Reader::errors_.size()
.Soooo, I guess I basically could implement this right now....lol. Expect a pull request shortly.
The text was updated successfully, but these errors were encountered: