Navigation Menu

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

replace regex with jena request parser #913

Closed
wants to merge 4 commits into from
Closed

replace regex with jena request parser #913

wants to merge 4 commits into from

Conversation

acoburn
Copy link
Contributor

@acoburn acoburn commented Sep 26, 2015

See: https://jira.duraspace.org/browse/FCREPO-1706

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

This removes the (incorrect) use of regular expressions in checking predicate values.

*
* @see <a href="https://jira.duraspace.org/browse/FCREPO-1409"> FCREPO-1409 </a> for details.
*/
private Optional<Quad> checkInvalidPredicates(final UpdateRequest request) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this returning/not-returning a Quad?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean: why a Quad instead of a predicate String? The only reason it's returning an Optional like this (instead of, e.g., a boolean) is so that the throw expression can include the problematic part of the statement in the message.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

... but from my perspective, it could be a Quad or something else. A Quad is easier, since that's what the source data consists of.

Copy link
Contributor

Choose a reason for hiding this comment

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

No, I mean why a Quad or anything else instead of some kind of information about what went wrong. Why is this code not returning some kind of description of a condition or conditions of invalidity?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could instead make this function return nothing and push the throw new IllegalArgumentExeption() into this function. Would you find that a cleaner implementation?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes. Another, more mannered approach would be to return Collection<? extends Exception>, which would allow for a more sophisticated report.

@acoburn
Copy link
Contributor Author

acoburn commented Sep 28, 2015

@ajs6f I replaced the Optional with a Collection<IllegalArgumentException>. However, I'm still not convinced that a list is all that appropriate here since the first incorrect predicate will trigger an exception. That is, why is it necessary to collect the 2nd, 3rd, etc error if the first one encountered will cause the request to fail? That's why I had used an optional in the first place, since I could just use the findFirst method on the Quad-stream.

@ajs6f
Copy link
Contributor

ajs6f commented Sep 28, 2015

Because with a Collection in hand, you can send back a response that contains advice about all the problematic predicates. No one wants to send a message, get a response that says, "This part is bad", correct it, send another message, get a response that says, "Oh, this other part is also bad." etc.

@acoburn
Copy link
Contributor Author

acoburn commented Sep 28, 2015

But then it would be better to respond with a Collection<String>. Then all the invalid predicates can be collected into a single thrown exception. Is that what you mean? The current implementation makes no sense to me.

@ajs6f
Copy link
Contributor

ajs6f commented Sep 28, 2015

No, an exception represents an error. A string is a message about the error. I'm saying that this method should return errors, not messages. It's up to other parts of the system to convert between the two. You can do other things with an Exception besides throw or catch it.

@acoburn
Copy link
Contributor Author

acoburn commented Sep 28, 2015

@ajs6f I pushed a new commit to this PR; is this more along the lines of what you mean?

final StringJoiner errorMessages = new StringJoiner(", ");
for (final IllegalArgumentException ex : errors) {
errorMessages.add(ex.getMessage());
}
Copy link
Contributor

Choose a reason for hiding this comment

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

No loop, just errors.stream().map(Exception::getMessage).collect(joining(",\n"))

@awoods
Copy link

awoods commented Oct 2, 2015

Resolved with: 6ea28b2

@awoods awoods closed this Oct 2, 2015
@acoburn acoburn deleted the fcrepo-1706 branch October 4, 2015 01:39
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

Successfully merging this pull request may close these issues.

None yet

4 participants