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

Fixes GH-2013 by traversing parents until sourceString is found #2014

Merged

Conversation

damyan-ognyanov
Copy link
Contributor

Fixes GH-2013 by traversing parents until sourceString is found

Signed-off-by: damyan.ognyanov damyan.ognyanov@ontotext.com

GitHub issue resolved: #2013

  • added a simplified test case reproducing the issue
  • fix in ASTServiceGraphPattern that traverse the node parents untl a sourceString is found

@damyan-ognyanov damyan-ognyanov added the 🐞 bug issue is a bug label Mar 18, 2020
Copy link
Contributor

@abrokenjester abrokenjester left a comment

Choose a reason for hiding this comment

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

Good find and fix, thanks @damyan-ognyanov ! One minor editorial remark, other than that LGTM.

sourceString = ((ASTUpdateSequence) theParent).getSourceString();
}
}
return sourceString;
Copy link
Contributor

Choose a reason for hiding this comment

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

I was wondering if maybe there could be a null check here, so that any exception is thrown when looking for the source string instead of when using the resulting string. Maybe return Objects.requireNonNull(sourceString);

Unless of course there is a case where returning null from getSourceString() is acceptable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thought of that for a while, but decided that if we did not found the sourceString at this point, something else was really messed up, so throwing a custom exception early, would not help much here since we do not have a resonable alternative to continue processing update further - a NPE will still be thrown in the code that uses it ...

@abrokenjester
Copy link
Contributor

abrokenjester commented Mar 19, 2020

Thanks @damyan-ognyanov . One more thing: could you please squash your commits?

Oh and also - we have revised our branch naming convention a little while back. For future fixes, could you please use the new convention? See https://rdf4j.org/documentation/developer/workflow/#workflow: it's basically GH-<issuenumber>-short-description, without the issues/ prefix.

Sorry for all the red tape requests - I promise this should be all of it :)

…test case

Signed-off-by: damyan.ognyanov <damyan.ognyanov@ontotext.com>
@damyan-ognyanov damyan-ognyanov force-pushed the issues/#2013-NPE-service-multiple-update-expressions branch from bb8c475 to 4023a7a Compare March 20, 2020 05:41
@damyan-ognyanov
Copy link
Contributor Author

@jeenbroekstra squashed commits but renaming it to follow the naming convention is a bit tricky since we already have this pull request refering to it...

@abrokenjester
Copy link
Contributor

That's all good, thanks, the branch naming thing was more for future reference.

@abrokenjester abrokenjester merged commit 670559d into master Mar 20, 2020
@abrokenjester abrokenjester deleted the issues/#2013-NPE-service-multiple-update-expressions branch March 20, 2020 22:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug issue is a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

NullPointerException when parsing SPARQL update with multiple expressions one of hich has SERVICE
3 participants