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

Return positions of parse errors found in JSON #10837

Closed
wants to merge 6 commits into from
Closed

Return positions of parse errors found in JSON #10837

wants to merge 6 commits into from

Conversation

markharwood
Copy link
Contributor

Extend SearchParseException and QueryParsingException to report position information in query JSON where errors were found. All query DSL parser classes that throw these exception types now pass the underlying position information (line and column number) at the point the error was found.

Closes #3303

…d only primitives and changed all of the parsers that throw QueryParsingExceptions which now mandates the passing of the error location info.
@markharwood
Copy link
Contributor Author

@s1monw New PR to replace #7891 - easier to start afresh than rebase old PR


package org.elasticsearch.common.xcontent;

public class XContentLocation {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we have some javadocs here and please make the class an all members final. I wonder if we should not even have getters here and make it a very simple struct

@s1monw
Copy link
Contributor

s1monw commented Apr 28, 2015

left some minor comments otherwise LGTM

@s1monw s1monw self-assigned this Apr 28, 2015
@s1monw
Copy link
Contributor

s1monw commented Apr 28, 2015

LGTM

@s1monw s1monw removed the review label Apr 28, 2015
@kimchy
Copy link
Member

kimchy commented Apr 28, 2015

if we are changing all the places that call QueryParserException, maybe we can change it to accept QueryParserContext, and then we can get the index name and the XContentParser from it (for the location). It will reduce the calling site for all those places, and will allow us to add more info if we want to the exception down the road.

@s1monw
Copy link
Contributor

s1monw commented Apr 28, 2015

if we are changing all the places that call QueryParserException, maybe we can change it to accept QueryParserContext, and then we can get the index name and the XContentParser from it (for the location). It will reduce the calling site for all those places, and will allow us to add more info if we want to the exception down the road.

lets do that in a sep PR?

@kimchy
Copy link
Member

kimchy commented Apr 28, 2015

lets do that in a sep PR?

sure (my thought was if we already change all this files now)

@markharwood
Copy link
Contributor Author

If there's no objections I'll revise this PR with @kimchy 's suggestion

@s1monw
Copy link
Contributor

s1monw commented Apr 28, 2015

ok sure go ahead @markharwood

…r. This change simplified the parser classes that throw exceptions but ElasticsearchExceptionTests and BytesRestResonse tests needed tweaking to work around the lack of QueryParseContext available in unit tests. I had to introduce a subclass of QueryParsingException which doesn’t require QueryParseContext to work but can still report on line/column number errors.
@markharwood
Copy link
Contributor Author

The change to pass QueryParseContext to QueryParsingException made all parser code cleaner.
One side effect was need for a protected constructor as a back door for unit tests that can't pass non-mockable QueryParseContext.
Good to go here?

* This constructor is provided for use in unit tests where a
* {@link QueryParseContext} may not be available
*/
protected QueryParsingException(Index index, int line, int col, String msg, Throwable cause) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it need to be protected? or just package private?

@javanna
Copy link
Member

javanna commented Apr 29, 2015

I had a quick look and I really like it, having the QueryParseContext as argument also addresses my concern about forgetting the location argument, that's great, left a couple of minor comments.

@markharwood
Copy link
Contributor Author

Thanks, @javanna - I moved the test exception out into same package in test framework and changed visibilities as per your comments

@s1monw
Copy link
Contributor

s1monw commented Apr 29, 2015

LGTM

@javanna
Copy link
Member

javanna commented Apr 29, 2015

LGTM too

@markharwood
Copy link
Contributor Author

Pushed to master 528f648

@clintongormley clintongormley changed the title Query enhancement: return positions of parse errors found in JSON Return positions of parse errors found in JSON Jun 7, 2015
@clintongormley clintongormley added :Search/Search Search-related issues that do not fall into other categories and removed :Query DSL labels Feb 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Search/Search Search-related issues that do not fall into other categories v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

REST error readability
5 participants