Skip to content
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

Error objects should also contain location information #1

Closed
mrennie opened this issue Mar 7, 2017 · 3 comments
Closed

Error objects should also contain location information #1

mrennie opened this issue Mar 7, 2017 · 3 comments
Assignees

Comments

@mrennie
Copy link

mrennie commented Mar 7, 2017

Consider the following snippet:

{
  "one": 1
  "two": 2
}

If you run parseTree on it, it parses fine (which is cool), but the error that is reported has no other information than the error code. It would be nice if each error also contained the location information so they could be found in source (for example in an editor or IDE).

Information that would be handy to have:

  1. the starting offset of the error
  2. the length of the bad stuff
  3. the column start of the error
  4. the line number
@aeschli aeschli closed this as completed in ef5fdb9 May 5, 2017
@aeschli aeschli self-assigned this May 5, 2017
@ulrichb
Copy link

ulrichb commented Jun 2, 2019

Hi @aeschli,

Offset and length is now part of ParseError. But what about the line number and column?

@aeschli
Copy link
Contributor

aeschli commented Jun 4, 2019

PR is welcome!

@ulrichb
Copy link

ulrichb commented Jun 4, 2019

@aeschli Would you prefer a) additional (redundant) members in ParseError ... or b) some utility function (jsonText: string, error: ParserError) => { line: number; column: number }?

I tend to option a (+ making the members of ParseError readonly).

Further: Should the numbers be 0-based (like in the TypeScript-API), or 1-based (like in the majority of similar language-parsing APIs)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants