Open greeny277 opened 6 years ago
I'm using version 2.6.4-SNAPSHOT. However, the Pellet reasoner already has this bug.
at least use a try{...}catch(Exception e){...} construct
That's a reasonable expectation but the issue here is more subtle.
There is a .next() on an empty iterator, and from the code I suspect there is an incorrect condition being checked:
if (dtReasoner.isSatisfiable(types))
{
if (!dtReasoner.containsAtLeast(2, types))
^^^^^^^^^^^^^^^ This is strange.
I think the !
is misplaced - it's trying to merge nodes when there are not at least two nodes, i.e., when there is one node or no nodes, like in this case. I suspect the intention was to only merge nodes when there are two or more nodes (and where the .next()
operation would have been safe)
{
/*
* This literal is a variable, but given _current ranges can only
* take on a single _value. Merge with that _value.
*/
final Object value = dtReasoner.valueIterator(types).next();
final ATermAppl valueTerm = dtReasoner.getLiteral(value);
Literal valueLiteral = _abox.getLiteral(valueTerm);
if (valueLiteral == null)
/*
* No dependency set is used here because omitting it prevents the
* constant literal from being removed during backtrack
*/
valueLiteral = _abox.addLiteral(valueTerm);
DependencySet mergeDs = DependencySet.INDEPENDENT;
for (final DependencySet ds : _depends.values())
mergeDs = mergeDs.union(ds, _abox.doExplanation());
_merge = new NodeMerge(this, valueLiteral, mergeDs);
}
}
Ah ok. So I guess it's a bug that can be easily fixed.
In fact I spend some weekends on it. It is harder to fix because simple change around this create problems elsewhere. It may need a modern rewrite with less mutable structures.
Hey.
I get a
NoSuchElementException
while reasoning. It appeared after I changed the datatype of a property fromxsd:decimal
toxsd:float
. It could be, that I made something wrong. Either way, I don't think that the reasoner should throw this exception and at least use atry{...}catch(Exception e){...}
construct.Best regards,
Christian