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

need better error messages for invalid jsonschemas #28

Open
b5 opened this issue May 21, 2018 · 2 comments
Open

need better error messages for invalid jsonschemas #28

b5 opened this issue May 21, 2018 · 2 comments

Comments

@b5
Copy link
Member

b5 commented May 21, 2018

Yesterday I made a bonehead mistake & wrote something like the following schema:

{
  "type" : "array",
  "fields": {
    "type" : "array",
    "fields": [
      { "name" : "foo", "type": "array", "extraField": "foobar" }
    ]
  }
}

So, uh there's a bunch of things wrong with ☝️

  • fields should be items (in both cases)
  • name should be title

The error returned gave me zero indication of how to fix the schema. This was in the context of adding data to qri, where problems can arise in a number of places, which sent me off hunting for bugs that didn't exist.

While I don't expect the returned error to catch something like "blah should actually be a blah field", jsonschemas can become quite large documents, so I'd like to upgrade parsing a jsonschema error returns to do two new things:

  • return a human-readable error that's as independent of go syntax as possible
  • return the _ first location in the document that failed to parse_

By "independant of go syntax", I mean we should try to say things like:
fields is not a valid jsonschema validator
and once I fix the first "fields" (but not the second), it'd be great if
items.fields is not a valid jsonschema validator
and when that's fixed:
items.fields.name is not a valid jsonschema validator, etc.

@handrews
Copy link

You might be interested in the discussion going on at json-schema-org/json-schema-spec#396 regarding possibly adding a recommended output/error format to the specification. Difficulty with error reporting has become a very common complaint across implementations.

@b5 b5 removed the ready label Jun 11, 2018
@b5 b5 added the backlog label Feb 18, 2019
@handrews
Copy link

Note that a set of output format recommendations did make it into the latest draft.

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

No branches or pull requests

2 participants