On 05/04/17 15:10, Chris Dollin wrote:
I've eyeballed the commits. Thanks, Andy. Two things:
E_Regex.java line 80 "we could non-eval exception."
<https://github.com/apache/jena/compare/master...afs:epimorphics_reports#diff-35f629317420ff3f22f8a6c927cbe26c>
I didn't understand the comment.
"We could throw a non-eval exception."
as per the commented code on the line after.
I found that there was no need to rebuild the exception in local
testing. During the expression build step, it is not inside a FILTER
catching ExprEvalException. And the stack is misleading as it would be
moved.
RegexXerces parallels the code of RegexJava and so
needs a similar change.
Sure - it isn't used by default.
RegexXerces is only needed for "x" flag which Java does not support.
I will run code when I have unbroken my Eclipse.
Chris
On 5 April 2017 at 14:23, Chris Dollin <[email protected]> wrote:
Thanks Andy I will look at them shortly.
I can clean up the unit test we used for the cancellation
case, it's fast but it only shows that closing the QueryIterSort
iterator closes the source iterator to -- I've been wondering
how to do an integration test that shows that the "didn't close"
warnings have gone away.
I will construct a test for the regex changes.
Chris
(struggling with Eclipse)
On 5 April 2017 at 13:15, Andy Seaborne <[email protected]> wrote:
Please take a look at the two commits on
https://github.com/afs/jena/tree/epimorphics_reports
One for regex, one for query cancellation in sorts.
Do you have a test or two (which aren't very slow)?
Andy
On 04/04/17 14:25, Chris Dollin wrote:
On 3 April 2017 at 16:30, Andy Seaborne <[email protected]> wrote:
What I proposed is to treat bad dynamic regexs as an evaluation error,
with warning, not a syntax error.
OK, I misunderstood.
Is that compatible with
the SPARQL spec? I looked at the relevant sections
and left unsure.
The spec says nothing about bad regexs.
So we /could/ say that evaluation an expression with a
syntactically illegal pattern terminated the query without
violating the spec. But we don't need to since the effect
we wanted was not to have enormous logs with a line
for each illegal regex, and we can use Log.warnOnce to
suppress duplicate messages.
[Of course the expression might evaluate differently
each time so there could still be lots of distinct
log lines but that's another edg on what's already an
edge case...]
I am happy with your 1/ and 2/ approach.
Chris
--
"What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck
Affair/
Epimorphics Ltd, http://www.epimorphics.com
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20
6PT
Epimorphics Ltd. is a limited company registered in England (number
7016688)
